[llvm-dev] cmpxchg on floats

JF Bastien via llvm-dev llvm-dev at lists.llvm.org
Wed Aug 26 08:57:51 PDT 2020



> On Aug 17, 2020, at 4:27 PM, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> 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?

That’s correct, but I’m mainly interested in bitwise comparison. That’s what C, C++, and (IMO) LLVM IR mean when an FP value is passed to cmpxchg.

Separately, there are operations such as atomic fadd and atomic fsub which make senses, can be supported directly by HW, and can have separate FP state.

I bring this up because I believe the discussion which started this thread can benefit from a bit wider perspective than “the LangRef says exactly *this*”.


More information about the llvm-dev mailing list