[llvm-dev] RFC: Atomic LL/SC loops in LLVM revisited

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Wed Jun 13 15:37:08 PDT 2018


Great writeup, thanks!

I'll respond to the rest in a bit, but I have a digression first...

One detail I hadn't noticed in my previous investigation is that the
"compare_exchange_weak" (or our IR "cmpxchg weak") operation is
theoretically unsound -- and NECESSARILY so.

As mentioned in this thread, there are architectural guarantees for forward
progress of an LLSC loop adhering to certain constraints. If your loop does
not meet those constraints, it may well livelock vs another CPU executing
the same loop, or even spuriously fail deterministically every time it's
executed on its own. This thread is all about a proposal to ensure that
LLVM emits LLSC loops such that they're guaranteed to meet the
architectural guarantees and avoid the possibility of those bad situations.

There is not to my knowledge any architecture which makes any guarantees
that an LLSC standing alone, without a containing loop, will not spuriously
fail. It may in fact fail every time it's executed. Of course, the typical
usage of compare_exchange_weak is to embed it within a loop containing
other user-code, but given that it contains arbitrary user code, there's
simply no way we can guarantee that this larger-loop meets the LLSC-loop
construction requirements. Therefore, it's entirely possible for some
particular compare_exchange_weak-based loop to livelock or to
deterministically spuriously fail. That seems poor, and exactly the kind of
thing that we'd very much like to avoid...

So, now I wonder -- is there actually a measurable performance impact (on,
say, ARM) if we were to just always emit the "strong" cmpxchg loop? I'm
feeling rather inclined to say we should not implement the weak variant at
all. (And, if others agree with my diagnosis here, also propose to
deprecate it from the C/C++ languages...)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180613/3cb76586/attachment.html>


More information about the llvm-dev mailing list