> On 06/02/2011 02:52 PM, Aldy Hernandez wrote:
>> Wouldn't it be better to pass the model (as an extra CONST_INT
>> operand) to the expanders?  Targets where atomic instructions always act
>> as full barriers could just ignore that argument, other could decide what
>> to do based on the value.
>> *shrug* I don't care.  Whatever everyone agrees on.
> Let's do that.  Many of the targets will be expanding these to
> a somewhat longer sequence at some stage, and they'll all be
> 95% identical.  The extra operand ought to make for less
> boiler-plate code.
>
>

OK, here's Aldy's patch modified to make the memory model a parameter to 
the RTL pattern.  I haven't worked with RTL for a while, so hopefully 
it's close to right :-)

If we can settle on the implementation, I'll proceed with the rest of 
the required atomics and then make the changes required to libstdc++-v3 
all at once.

Fortran seems to decide to copy only some of builtin-types.def in its 
own private types.def... dare I ask why?

Other changes...

Rather than duplicating the code, expand_sync_mem_exchange() now 
calls expand_sync_lock_test_and_set() if there is no sync_mem_exchange 
pattern.  This will mean when libstdc++ is converted to directly use the 
new __sync_mem_exchange, all existing architectures will still work as 
they do today, even if they dont provide the new patterns.  That should 
ease the transition if the current behaviour is retained.

I'm also now inserting a _sync_synchronize() before expanding the 
lock_test_and_set() IFF the memory model is 'acq_rel' or 'seq_cst'. My 
understanding is that lock_test_and_set() is defined to be an acquire 
barrier only, and the results may not be correct without the extra 
synchronization.  (the processor is free to delay stores after the 
instruction if is only an acquire barrier)  I assume the compiler's 
lock_test_and_set builtin is considered to have the same characteristics 
as the intel instruction...      for the i386 port, i turned 
mem_exchange into a define_expand to issue the barrier if need be, and 
then follow it with the current lock_test_and_set insn.

Finally, I moved the definition of the various memmodel modes to 
machmode.h from tree.h.  This allows rtl pattern code to check memory 
order values during the expansion of patterns/insns.

So my rusty hands screwed around with the patch quite a bit... have a 
look.  thoughts?

bootstraps and no regressions on x86_64-unknown-linux.  Do we apply this 
to mainline?  or cxx-mem-model and then bring it all over later when 
they are all done and "perfected" ?

Andrew