We've relaxed `atomicrmw xchg` to support floating point types but not cmpxchg -- the cmpxchg comparison behavior is not a floating point comparison, so that would be potentially misleading. I'd say adding the assertion is a good idea. Cheers, Nicolai On Thu, Aug 13, 2020 at 10:59 PM Chris Lattner via llvm-dev <llvm-dev at lists.llvm.org> wrote:> > Does the code generator support this? If not, we should add an assertion to the verifier. If so, we can consider relaxing langref or making it more specific about floats. > > -Chris > > On Aug 13, 2020, at 6:35 AM, Alex Zinenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi LLVM-dev, > > when working on MLIR-to-LLVM-IR conversion, I noticed that it is possible to programmatically construct a cmpxchg instruction operating on floats (or actually any type since there is no assertion on pointer element type here https://github.com/llvm/llvm-project/blob/9c2e708f0dc547d386ea528450a33ef4bd2a750b/llvm/lib/IR/Instructions.cpp#L1501), but LangRef specifies that only integers and pointers are accepted (https://llvm.org/docs/LangRef.html#cmpxchg-instruction). Does somebody rely on other types being accepted in cmpxchg or should we add an assertion for the element type to match the LangRef? > > -- > Alex > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.
We (C, C++, and LLVM) are generally moving towards supporting FP as a first-class thing with all atomic operations †, including cmpxchg. It’s indeed *usually* specified as a bitwise comparison, not a floating-point one, although IIRC AMD has an FP cmpxchg. Similarly, some of the operations are allowed to have separate FP state (say, atomic add won’t necessarily affect the scalar FP execution’s exception state, might have a different rounding mode, etc). I’m OK with MLIR matching the current state of LLVM, but I want to point out that the docs might be incorrect, or are expected to change in the future. † See http://wg21.link/p0020 <http://wg21.link/p0020> as well as r360421 D58251 D50491 D26266 D26266 r264845 D15471> On Aug 14, 2020, at 6:15 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > We've relaxed `atomicrmw xchg` to support floating point types but not > cmpxchg -- the cmpxchg comparison behavior is not a floating point > comparison, so that would be potentially misleading. I'd say adding > the assertion is a good idea. > > Cheers, > Nicolai > > On Thu, Aug 13, 2020 at 10:59 PM Chris Lattner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> >> Does the code generator support this? If not, we should add an assertion to the verifier. If so, we can consider relaxing langref or making it more specific about floats.I agree with this. Generally it’s a bit tricky because, some of these are tied to the atomic expand pass, where a backend says what it supports.>> -Chris >> >> On Aug 13, 2020, at 6:35 AM, Alex Zinenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi LLVM-dev, >> >> when working on MLIR-to-LLVM-IR conversion, I noticed that it is possible to programmatically construct a cmpxchg instruction operating on floats (or actually any type since there is no assertion on pointer element type here https://github.com/llvm/llvm-project/blob/9c2e708f0dc547d386ea528450a33ef4bd2a750b/llvm/lib/IR/Instructions.cpp#L1501), but LangRef specifies that only integers and pointers are accepted (https://llvm.org/docs/LangRef.html#cmpxchg-instruction). Does somebody rely on other types being accepted in cmpxchg or should we add an assertion for the element type to match the LangRef? >> >> -- >> Alex >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > -- > Lerne, wie die Welt wirklich ist, > aber vergiss niemals, wie sie sein sollte. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200814/85d8e302/attachment.html>
On Fri, Aug 14, 2020 at 7:42 PM JF Bastien <jfbastien at apple.com> wrote:> We (C, C++, and LLVM) are generally moving towards supporting FP as a first-class thing with all atomic operations †, including cmpxchg. It’s indeed *usually* specified as a bitwise comparison, not a floating-point one, although IIRC AMD has an FP cmpxchg.We do, but this should arguably be a different instruction because it behaves differently from bitwise compare. Cheers, Nicolai> Similarly, some of the operations are allowed to have separate FP state (say, atomic add won’t necessarily affect the scalar FP execution’s exception state, might have a different rounding mode, etc). > > I’m OK with MLIR matching the current state of LLVM, but I want to point out that the docs might be incorrect, or are expected to change in the future. > > † See http://wg21.link/p0020 as well as r360421 D58251 D50491 D26266 D26266 r264845 D15471 > > On Aug 14, 2020, at 6:15 AM, Nicolai Hähnle via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > We've relaxed `atomicrmw xchg` to support floating point types but not > cmpxchg -- the cmpxchg comparison behavior is not a floating point > comparison, so that would be potentially misleading. I'd say adding > the assertion is a good idea. > > Cheers, > Nicolai > > On Thu, Aug 13, 2020 at 10:59 PM Chris Lattner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > > Does the code generator support this? If not, we should add an assertion to the verifier. If so, we can consider relaxing langref or making it more specific about floats. > > > I agree with this. Generally it’s a bit tricky because, some of these are tied to the atomic expand pass, where a backend says what it supports. > > > -Chris > > On Aug 13, 2020, at 6:35 AM, Alex Zinenko via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi LLVM-dev, > > when working on MLIR-to-LLVM-IR conversion, I noticed that it is possible to programmatically construct a cmpxchg instruction operating on floats (or actually any type since there is no assertion on pointer element type here https://github.com/llvm/llvm-project/blob/9c2e708f0dc547d386ea528450a33ef4bd2a750b/llvm/lib/IR/Instructions.cpp#L1501), but LangRef specifies that only integers and pointers are accepted (https://llvm.org/docs/LangRef.html#cmpxchg-instruction). Does somebody rely on other types being accepted in cmpxchg or should we add an assertion for the element type to match the LangRef? > > -- > Alex > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > > > -- > Lerne, wie die Welt wirklich ist, > aber vergiss niemals, wie sie sein sollte. > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-- Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.
On Fri, Aug 14, 2020 at 10:42:02AM -0700, JF Bastien via llvm-dev wrote:> We (C, C++, and LLVM) are generally moving towards supporting FP as a > first-class thing with all atomic operations †, including cmpxchg. It’s > indeed *usually* specified as a bitwise comparison, not a floating-point > one, although IIRC AMD has an FP cmpxchg. Similarly, some of the > operations are allowed to have separate FP state (say, atomic add won’t > necessarily affect the scalar FP execution’s exception state, might > have a different rounding mode, etc).We don't really FP cmpxchg in hardware to implement it, do we? It can be lowered as load, FP compare, if not equal cmpxchg load? Joerg