[LLVMdev] compare and swap

Torvald Riegel torvald at se.inf.tu-dresden.de
Thu Feb 21 03:51:02 PST 2008


On Thursday 21 February 2008 19:19, Chandler Carruth wrote:
> 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.

CAS is compare-and-SET. 

>
> > 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

X86 provides the flag.

> 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.

If the codegen can really do it if necessary, then this is fine. Having two 
intrinsics is not perfect, but it might give programmers more confidence in 
the generated code.

Torvald



More information about the llvm-dev mailing list