<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> > 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.)<br>
<br>
><br>
<br>
><br>
<br>
> 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.<br>
<br>
<br>
</span>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.<br></blockquote><div><br></div><div>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.</div></div></div></div>