Follow up on 431e3138a and complete the other possible combinations.
Besides enforcing the new behavior it also mitigates several TSAN false positives
when combining orders that used to be stronger and therefore not allowed.
Paths
| Differential D101501
[CGAtomic] Lyft strong requirement for remaining compare_exchange combinations ClosedPublic Authored by bruno on Apr 28 2021, 5:09 PM.
Details
Summary Follow up on 431e3138a and complete the other possible combinations. Besides enforcing the new behavior it also mitigates several TSAN false positives
Diff Detail Event TimelineThis revision is now accepted and ready to land.May 3 2021, 4:39 PM Comment Actions Your change is correct, but I think there's a deeper flaw in this code.
Comment Actions Don't mind JF, he's just forgotten that C++ lacks the ability to turn the typically constant value arguments passed to functions like std::atomic::compare_exchange_strong into actual compile-time constants to the builtin used within those functions, so his advice would mean emitting all atomics in C++ as sequentially consistent. Bruno, I think it would be straightforward to just fix this now; you just need to make creating AcquireBB and SeqCstBB unconditional. If you think there's a good reason not to do that in one patch, I won't insist, but it feels to me like the right patch. Comment Actions
Ugh right you are ☹️ Comment Actions
C++ often pushing towards the harsh reality!
Fair enough, will do! Thanks for bringing it up.
Why not a small paper? :D Comment Actions
It's almost funny how much IR this generates at -O0 (and a fix here will make it worse, of course). I wish it worked any other way. :) bruno retitled this revision from [CGAtomic] Handle memory_order_consume failing order on compare_exchange to [CGAtomic] Lyft strong requirement for remaining compare_exchange combinations. Comment ActionsUpdate after @rjmccall comments! Comment Actions Forgot to add the Differential tag, my bad. Closed by https://reviews.llvm.org/rG819e0d105e84
Revision Contents
Diff 343556 clang/lib/CodeGen/CGAtomic.cpp
clang/test/CodeGen/atomic-ops.c
clang/test/CodeGenOpenCL/atomic-ops.cl
llvm/lib/AsmParser/LLParser.cpp
llvm/lib/IR/Instructions.cpp
llvm/lib/IR/Verifier.cpp
|
Is this logic correct post-C++17? It looks like if you request a relaxed success order and an acquire failure order, this will use a relaxed order for both. That used to be okay because of the no-stronger restriction, but I think it's just invalid now, and all the conditionality needs to be removed.