[PATCH] D15592: [LICM] Make store promotion work in the face of unordered atomics
JF Bastien via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 4 00:59:04 PST 2016
> > > On the topic of infinite loops, I could go either way. In practice,
> any infinite loop will have a safepoint or deoptimization point within it,
> so the loop promotion couldn't trigger anyways. Given that, I don't see
> any reason why we'd need to treat potentially infinite loops specially
> here. (Again, C++'s rules are not relevant.)
> > I understand, and the fact that this can't come up in your environment
> is interesting. However, from LLVM's perspective, we still need to decide
> on the semantics here.
> I think the answer should be that "unordered" atomics are treated like
> normal non-atomic instructions in all ways *except* that the actual memory
> operation is atomic. Thus, there are no special requirement about infinite
That's totally fine by me. My concern is that C++ relaxed atomics
inadvertently gain the same semantics. Maybe not in your patch, but through
further refactoring. That's why I ask for negative tests on relaxed
atomics: to catch if they ever start doing the wrong thing.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-commits