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
