RFC: add "cmpxchg weak" to LLVM IR

Chandler Carruth chandlerc at google.com
Fri Jun 13 02:45:14 PDT 2014

On Thu, Jun 12, 2014 at 5:22 PM, Tim Northover <t.p.northover at gmail.com>

> I've decided the next step in atomics is the weak compare-and-exchange
> operation. As with the failure order, I'm going t outline the
> direction I'd like to take:
> 1. All cmpxchg instructions now return { iN, i1 } where the first
> value is what we got before (the loaded result), the second == 1 if an
> exchange took place.
> 1. "weak" is an optional modifier to the cmpxchg instructions. If
> anyone wants a bikeshed to paint, this would be a good one. I wasn't
> sure myself.
> Theoretically, we could only modify the return type of the weak
> variant, but I think that making it a global change helps keep the IR
> uniform. Additionally, this extra bit actually exists on most
> platforms even for the strong cmpxchg: on LL/SC ones by virtue of
> control flow, and x86 (for example) sets ZF based on it.

Ok, I've mulled over all of the IR-level memory model changes. While I
didn't *really* doubt that this was the right way to go, I'm increasingly
happy with it.

I specifically increasingly happy with the { iN, i1 } result. I do wish we
had a better way in the IR to model this entire concept (which we see in
the overflow arithmetic intrinsics as well) but we don't. With the current
IR, this is clearly the best design (and I feel bad that I argued against
it in the original design discussion years ago... ah, hindsight). If we
ever figure out a better way to model this kind of operation, then we can
reconsider all of them in light of that, but I'm not sure when or if that
day will even arrive.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140613/fce1fd15/attachment.html>

More information about the llvm-commits mailing list