[PATCH] D59345: Allow code motion (and thus folding) for atomic (but unordered) memory operands

[Philip Reames via Phabricator via llvm-commits]

reames added a comment.

In D59345#1429273 <https://reviews.llvm.org/D59345#1429273>, @jfb wrote:

> Overall this looks good.
>  Do you have tests with intervening fences (both atomic and thread), to make sure they block motion as expected?


I don't, but will add some before submitting.  Good idea.

> I'm trying to figure out if this optimization is only correct for `memory_order_java`, or if it also applies to `memory_order_relaxed`. I can't see a case in your examples which wouldn't apply to `memory_order_relaxed` as well. @__simt__ WDYT?
>  I'm not asking you to do that work. It just seems like a valid follow-up.

I'm not sure.  I believe that memory_order_relaxed maps to llvm's monotonic right?  If so, then I *think* moving one is safe, but monotonic is just subtly different enough from unordered and not atomic that a more careful audit would be needed.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59345/new/

https://reviews.llvm.org/D59345