This is an archive of the discontinued LLVM Phabricator instance.

Allow code motion (and thus folding) for atomic (but unordered) memory operands
ClosedPublic

Authored by reames on Mar 13 2019, 9:28 PM.

Details

Summary

Building on the work done in D57601, now that we can distinguish between atomic and volatile memory accesses, go ahead and allow code motion of unordered atomics. As seen in the diffs, this allows much better folding of memory operations into using instructions. (Mostly done by the PeepholeOpt pass.)

Note: I have not reviewed all callers of hasOrderedMemoryRef since one of them - isSafeToMove - is very widely used. I'm relying on the documented semantics of each method to judge correctness.

Diff Detail

Repository
rL LLVM

Event Timeline

reames created this revision.Mar 13 2019, 9:28 PM
Herald added a project: Restricted Project. · View Herald TranscriptMar 13 2019, 9:28 PM
jfb added a subscriber: __simt__.Mar 14 2019, 8:34 AM
jfb accepted this revision.Mar 14 2019, 8:36 AM

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

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.

This revision is now accepted and ready to land.Mar 14 2019, 8:36 AM
In 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.

jfb added a comment.Mar 14 2019, 10:06 AM

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.

Yes, memory_order_relaxed is monotonic.

This revision was automatically updated to reflect the committed changes.