x86 softfloat target: no way to get LLVM to make local use of the FPU or SIMD registers

[RalfJung]

Some softfloat targets are used in environments where an FPU and SIMD registers are present, but should not be used by default -- in particular, this is fairly common in kernels. It should be possible to still locally enable the use of these CPU features; this just adds a precondition to the function to make FPU and SIMD ready for use by the kernel before invoking this code.

This works fine on arm-32 by picking a softfloat ABI (i.e., a *eabi target) and then enabling the right target features on a function-by-function basis. However, for x86 (32bit and 64bit), this does not work: there is no dedicated ABI flag supported by LLVM here; instead, our soft-float targets work by setting target features to something like -x87,-mmx,-sse,+soft-float. When both the soft-float and the sse2 target feature are set, soft-float takes priority (example). We cannot let people disable soft-float on a per-function basis as that would change the ABI.

Ultimately this is caused by the fact that LLVM doesn't have a proper float ABI designation for x86; instead, the float ABI is inferred from target features such as soft-float. If we could set the float ABI directly like we can on arm-32, we could let people disable soft-float on a per-function basis (probably via a hard-float target feature, no need to make this a negative feature) and thus LLVM could generate code making proper use of the FPU.

Cc @nikic @workingjubilee @briansmith

[RalfJung]

This should probably be filed as a feature request on the LLVM side as well? This is not something we can do without LLVM support, I think.

[briansmith]

You mentioned x86 and arm-32. How about x86_64 and Aarch64? I think those are the ones people are most concerned about.

[nikic]

The ask here is basically the same as #134375 but for x86 instead of aarch64, right? It's something I started working on (https://github.com/nikic/llvm-project/commits/aarch64-soft-float-abi), but it will probably be a while before I can get back to this.

[briansmith]

I noticed that this is labled "A-floating-point" and the discussion mentions floating point, but the bigger need is for non-floating point SIMD register use.

[RalfJung]

You mentioned x86 and arm-32. How about x86_64 and Aarch64? I think those are the ones people are most concerned about.

By "x86" I mean x86-32 and x86-64.

aarch64 is its own mess, it doesn't even have a soft-float target feature in LLVM so we don't just have a problem of "it generates bad code", we have a problem of "this is just unsound". The relevant upstream issue here is llvm/llvm-project#110632, and as Nikita mentioned our own issue for this is #134375.

The ask here is basically the same as #134375 but for x86 instead of aarch64, right?

Hm, maybe. On x86 the situation is better than on aarch64 insofar as we don't have a soundness problem. I would say "enabling the target feature does basically nothing" is better than "enabling the target feature causes unsoundness", but YMMV. ;)

I noticed that this is labled "A-floating-point" and the discussion mentions floating point, but the bigger need is for non-floating point SIMD register use.

I updated labels and description.

[briansmith]

If this affects x86_64 then it is a much bigger deal than for x86. Could you update the description for that?

[RalfJung]

LLVM uses X86 as the name for both the 32bit and 64bit version of this architecture, so my use of this term certainly has precedent, and I think the issue title is already long enough. I made the issue description more explicit.