[PATCH] D15592: [LICM] Make store promotion work in the face of unordered atomics

[JF Bastien via llvm-commits]

>
> > > 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>