[libc-commits] [PATCH] D118099: [libc][NFC] Fix GCC inline asm compilation problems + workaround clang assertion

Roland McGrath via Phabricator via libc-commits libc-commits at lists.llvm.org
Tue Jan 25 14:19:37 PST 2022

mcgrathr added a comment.

In D118099#3269740 <https://reviews.llvm.org/D118099#3269740>, @abrachet wrote:

> In D118099#3268320 <https://reviews.llvm.org/D118099#3268320>, @sivachandra wrote:
>> That a compiler unnecessarily requires the `"cc"` clobber specification is OK but GCC requiring the input operand to have the `"f"` modifier instead of the `"t"` modifier seems not so correct. Should we really care about the GCC problem now?
> Ok I've committed without the changes to `sqrtl`

When something arcane like this is there for a specific reason like working around a compiler bug, then this should always have comments and ideally those comments should have URLs to the compiler bug report so in future it's clear why something is there and when it can be removed.  If these instructions don't actually touch the condition codes in hardware, then a proper asm would not say they do.  If there's a need to do something other than what the instruction's hardware definition should suggest, it needs a comment.  Instructions like fsqrt are documented in the Intel manual to touch the FPU status flags.  Perhaps GCC is using the "cc" clobber to also indicate the condition code-like portions of the FPU status register.  (However, I don't see any indications of this in GCC's source where it emits fsqrt itself.)

In the case of "f" vs "t" I think this is a misuse of the constraint semantics, which are specified by GCC.  The "t" constraint for x86 is a specific register, not a class of registers.  In GCC, when two operands must actually be the same thing exactly then this must be specified directly by using a matching constraint (just digits).  So here, you need to use "=t" in the output and then "0" in the input to say that the input operand must be identical to the output operand.  Otherwise you're saying they should be two separate operands that both meet the "t" constraint.  Since that constraint is only met by a single register, that's impossible.  Using the "f" constraint tells it to use some other x87 register, which won't be the actual input to the machine instruction.

  rG LLVM Github Monorepo



More information about the libc-commits mailing list