[LLVMdev] compare and swap

[Chandler Carruth]

Torvald Riegel wrote:
> On Wednesday 20 February 2008 01:51, Andrew Lenharth wrote:
>> Anyone have an idea?  The patch as it stands is attached below.  X86
>> is a pseudo instruction because the necessary ones and prefixes aren't
>> in the code gen yet, but I would imagine they will be (so ignore that
>> ugliness).  The true ugliness can be seen in the alpha impl which open
>> codes it, including a couple relative branches.  The code sequence for
>> alpha is identical to ppc, mips, and arm, so it would be nice to lower
>> these to the correct sequences before code gen rather than splitting
>> (or hiding as I did here) basic blocks after code gen.
> 
> Andrew,
> 
> why is the intrinsic name not CAS?

Because, fundamentally, it loads, compares, and conditionally stores. 
There is no concept of a "swap" in SSA, so removing that aspect of the 
atomic primitives makes the *LLVM* representation easier to understand.

> And having another version that returns 
> just a bool might be better in some cases ( 1. does  CAS return the value on 
> all architectures?

Check the page (http://chandlerc.net/llvm_atomics.html -- the 
implementation info is still current, even though the docs are not) for 
how this gets implemented. As Andrew has already pointed out, on x86, 
the LLVM behavior maps to the underlying architecture. Other 
architectures which might avoid a compare can easily do so by pattern 
matching in the codegen. I'm not saying this is 100% correct mapping of 
all architectures, but it seems very clean, and not to introduce 
performance issues on any.

> 2. you can just jump based on a flag and don't need to 
> compare it again). Just my 2 cents though ...

Again, pattern matching can enable the architectures which don't need to 
compare again, to in fact not do so, but some architectures will *need* 
to compare again in order to determine the bool value.

My strongest feeling is that "swap" has no place in an SSA IR, and the 
idea of atomically loading, comparing, and storing is far more in 
keeping. In fact, I thought the "swap" instrinsic had even been re-named 
to "ls" for load-store at some point this summer.. Do you have those 
changes Andrew? In any event, those are the reasons I had for moving 
away from "swap" in the design process, and as Andrew said he was 
primarily basing the implementation on that work.

-Chandler

> 
> torvald
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev