Page MenuHomePhabricator

[X86] avoid assert with varargs, soft float, and no-implicit-float

Authored by inglorion on Jun 9 2021, 6:06 PM.




  • PR36507 Floating point varargs are not handled correctly with -mno-implicit-float
  • PR48528 __builtin_va_start assumes it can pass SSE registers when using -Xclang -msoft-float -Xclang -no-implicit-float

On x86_64, floating-point parameters are normally passed in XMM
registers. For va_start, we spill those to memory so va_arg can
find them. There is an interaction here with -msoft-float and

When -msoft-float is in effect, instead of passing floating-point
parameters in XMM registers, they are passed in general-purpose

When -no-implicit-float is in effect, it "disables implicit
floating-point instructions" (per the LangRef). The intended
effect is to not have the compiler generate floating-point code
unless explicit floating-point operations are present in the
source code, but what exactly counts as an explicit floating-point
operation is not specified. The existing behavior of LLVM here has
led to some surprises and PRs.

This change modifies the behavior as follows:

| soft | no-implicit | old behavior    | new behavior    |
|  no  |   no        | spill XMM regs  | spill XMM regs  |
| yes  |   no        | don't spill XMM | don't spill XMM |
|  no  |  yes        | don't spill XMM | spill XMM regs  |
| yes  |  yes        | assert          | don't spill XMM |

In particular, this avoids the assert that happens when
-msoft-float and -no-implicit-float are both in effect. This
seems like a perfectly reasonable combination: If we don't want
to rely on hardware floating-point support, we want to both
avoid using float registers to pass parameters and avoid having
the compiler generate floating-point code that wasn't in the
original program. Instead of crashing the compiler, the new
behavior is to not synthesize floating-point code in this
case. This fixes PR48528.

The other interesting case is when -no-implicit-float is in
effect, but -msoft-float is not. In that case, any floating-point
parameters that are present will be in XMM registers, and so we
have to spill them to correctly handle those. This fixes
PR36507. The spill is conditional on %al indicating that
parameters are present in XMM registers, so no floating-point
code will be executed unless the function is called with
floating-point parameters.

Diff Detail

Event Timeline

inglorion created this revision.Jun 9 2021, 6:06 PM
inglorion requested review of this revision.Jun 9 2021, 6:06 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 9 2021, 6:06 PM
rnk accepted this revision.Jun 14 2021, 12:27 PM


The spill is conditional on %al ...

Yeah, that is a fun detail.

This revision is now accepted and ready to land.Jun 14 2021, 12:27 PM