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. OtherX86 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
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
On 2/21/08, Chandler Carruth <chandlerc at gmail.com> wrote:> 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.Swap seemed much more logical than ls. Memory isn't in SSA form, and swapping a value in memory makes perfect sense in LLVM. LS isn't bad and for operations where something happens in between (add or compare) it makes sense. I guess the question is it a better naming convention: L Op S or the terms the ops are normally known by (swap, cas, etc). I don't think we need the other intrinsics (esp lss), so I haven't added them yet. If there is a compelling case why the other ones you have are necessary, then we could add them. Andrew
Andrew Lenharth wrote:> Swap seemed much more logical than ls. Memory isn't in SSA form, and > swapping a value in memory makes perfect sense in LLVM.I guess I always tried to make the intrinsics fit SSA form rather than memory representations. Within the backend it certainly makes more sense to tie them more firmly to the underlying hardware representations, I felt the load [op] store model fit SSA very well while lowering cleanly to the hardware, even when [op] is omitted. Either way though, its just a matter of syntax and fluff, not substance. =D -Chandler > LS isn't bad> and for operations where something happens in between (add or compare) > it makes sense. I guess the question is it a better naming > convention: > L Op S > or the terms the ops are normally known by (swap, cas, etc). > > I don't think we need the other intrinsics (esp lss), so I haven't > added them yet. If there is a compelling case why the other ones you > have are necessary, then we could add them.The only other one was "lss" i thought? The only reason I know of for that one is that x86 happens to support it directly (lock; xsub iirc...), but if that is even a common use case, it could likely be extracted by the backend rather than representing it in the IR... i think? -Chandler> > Andrew > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev