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

Tim Northover via llvm-dev llvm-dev at lists.llvm.org
Thu Jun 14 02:28:44 PDT 2018

>   * I'd like to see ARM+AArch64+Hexagon move away from the problematic
>   expansion in IR and to have that code deleted from AtomicExpandPass. Are
>   there any objections?

I think it would be a great shame and I'd like to avoid it if at all
possible, though I'm also uncomfortable with the current situation.

The problem with late expansion is that even the simplest variants add
some rather unpleasant pseudo-instructions, and I've never even seen
anyone attempt to get good CodeGen out of it (simplest example being
"add xD, xD, #1" in the loop for an increment but there are obviously
more). Doing so would almost certainly involve duplicating a lot of
basic arithmetic instructions into AtomicRMW variants.

Added to that is the fact that actual CPU implementations are often a
lot less restrictive about what can go into a loop than is required
(for example even spilling is fine on ours as long as the atomic
object is not in the same cache-line; I suspect that's normal). That
casts the issue in a distinctly theoretical light -- we've been doing
this for years and as far as I'm aware nobody has ever hit the issue
in the real world, or even had CodeGen go wrong in a way that *could*
do so outside the -O0 situation.

OTOH that *is* an argument for performance over correctness when you
get right down to it, so I'm not sure I can be too forceful about it.
At least not without a counter-proposal to restore guaranteed


More information about the llvm-dev mailing list