On Thu, Oct 17, 2013 at 3:10 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Thu, Oct 17, 2013 at 12:22 AM, Noah Misch <noah@leadboat.com> wrote:
>> Removing support for alpha is a different animal compared to removing support
>> for non-gcc MIPS and most of the others in your list. A hacker wishing to
>> restore support for another MIPS compiler would fill in the assembly code
>> blanks, probably using code right out of an architecture manual. A hacker
>> wishing to restore support for alpha would find himself auditing every
>> lock-impoverished algorithm in the backend.
>
> I had much the same thought last night. So I reverse my vote on
> Alpha: let's drop it. I had thought that perhaps there'd be some
> value in keeping it to force ourselves to consider what will happen
> under the weakest generally-understood memory model, but in fact
> that's probably a doomed effort without having the hardware available
> to test the code. As you say, any future atomics support for such a
> platform will be a major undertaking.
FWIW, I think that if we approach coding lock free algorithms
correctly - i.e. "which memory barriers can we avoid while being
safe", instead of "which memory barriers we need to add to become
safe" - then supporting Alpha isn't a huge amount of extra work. We
only need a couple of extra barriers after atomic reads where I think
we should have a comment anyway explaining that we don't need a read
barrier because a data dependency provides ordering.
In general I agree that we are unlikely to provide a bug free result
without a build farm animal, so I'm ±0 on removing support. We can try
to support, but we are unlikely to succeed. I also find it unlikely
that anyone will create a new architecture with a similarly loose
memory model. The experience with Alpha and other microprocessors
shows that the extra hardware needed for fast and strong memory
ordering guarantees more than pays for itself in performance.
Regards,
Ants Aasma