[llvm-commits] [llvm] r137403 - /llvm/trunk/docs/Atomics.html

[Andrew Trick]

On Aug 11, 2011, at 6:55 PM, Eli Friedman wrote:

>>   <dt>Relevant standard</dt>
>> @@ -344,11 +345,17 @@
>>       reason about for the programmer than other kinds of operations, and using
>>       them is generally a practical performance tradeoff.</dd>
>>   <dt>Notes for optimizers</dt>
>> -  <dd>In general, optimizers should treat this like a nothrow call; the
>> -      the possible optimizations are usually not interesting.</dd>
>> +  <dd>In general, optimizers should treat this like a nothrow call.
>> +      However, optimizers may improve performance by reordering a
>> +      store followed by a load unless both operations are sequentially
>> +      consistent.</dd>
> 
> It's legal, but how is it likely to improve performance?  I can't
> think of any transformation that would try to do this... maybe GVN?

Yes, maybe GVN. This may be more of a codegen issue, and somewhat architecture specific. I think it's safe to say though that for any architecture, if a load can be scheduled above a fence, it should be. But I don't want to make such a specific statement in this doc.

>>   <dt>Notes for code generation</dt>
>> -  <dd>SequentiallyConsistent operations generally require the strongest
>> -      barriers supported by the architecture.</dd>
>> +  <dd>SequentiallyConsistent loads minimally require the same barriers
>> +    as Acquire operations and SequeuentiallyConsistent stores require
>> +    Release barriers. Additionally, the code generator must enforce
>> +    ordering between SequeuentiallyConsistent stores followed by
>> +    SequeuentiallyConsistent loads. On common architectures, this
>> +    requires emitting a full fence after SequeuentiallyConsistent stores.</dd>
>>  </dl>
> 
> See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2745.html
> ?  It's actually kind of nasty: you can implement seq_cst load/store
> by add a fence for either the load or the store, and people don't
> appear to be making the choice consistently.

Absolutely. Please reword this in your own language.

Thanks,
-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110811/9d4200e5/attachment.html>