[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
> loops.

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...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160204/f7c318b6/attachment.html>

More information about the llvm-commits mailing list