Re: should sync builtins be full optimization barriers?

[Paolo Bonzini <bonzini at gnu dot org>]

On 09/09/2011 04:22 PM, Andrew MacLeod wrote:
> >
> Yeah, some of this is part of the ongoing C++0x work... the memory model
> parameter is going to allow certain types of code movement in optimizers
> based on whether its an acquire operation, a release operation, neither,
> or both.    It is ongoing and hopefully we will eventually have proper
> consistency.  The older __sync builtins are eventually going to invoke
> the new__sync_mem routines and their new patterns, but will fall back to
> the old ones if new patterns aren't specified.
>
> In the case of your program, this would in fact be a valid
> transformation I believe...  __sync_lock_test_and_set is documented to
> only have ACQUIRE semantics.

Yes, that's true.  However, there's nothing special in the compiler to 
handle __sync_lock_test_and_set differently (optimization-wise) from say 
__sync_fetch_and_add.

> I don't see anything in this pattern however that would enforce acquire
> mode and prevent the reverse operation.. moving something from after to
> before it... so there may be a bug there anyway.

Yes.

> And I suspect most people actually expect all the old __sync routines to
> be full optimization barriers all the time...  maybe we should consider
> just doing that...

That would be very nice.  I would like to introduce that kind of data 
structure in QEMU, too. :)

Paolo