-
Notifications
You must be signed in to change notification settings - Fork 13.6k
Open
Copy link
Labels
A-ABIArea: Concerning the application binary interface (ABI)Area: Concerning the application binary interface (ABI)A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.F-f16_and_f128`#![feature(f16)]`, `#![feature(f128)]``#![feature(f16)]`, `#![feature(f128)]`O-x86_32Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)S-waiting-on-LLVMStatus: the compiler-dragon is eepy, can someone get it some tea?Status: the compiler-dragon is eepy, can someone get it some tea?
Description
On 32-bit x86, the ABI specifies that f16 gets returned in xmm0, which is what Clang and GCC do (neither Clang nor GCC support _Float16 when SSE2 is disabled)
So... for the "Rust" ABI we can do our own thing bypassing this (likely similar fo f32
/f64
, we should just always return f16
in via PassMode::Indirect
), but what shall we do for the extern "C"
ABI? We'll need a new dedicated compiler error (likely as part of the pass that we are adding here) that rejects returning f16
when the SSE registers are not available.
That will mean that libcore does not compile on i586 targets.... Actually libcore uses the "Rust" ABI so that one is fine. But if we have extern "C"
float functions somewhere those would not be portable any more.
Metadata
Metadata
Assignees
Labels
A-ABIArea: Concerning the application binary interface (ABI)Area: Concerning the application binary interface (ABI)A-LLVMArea: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues.C-bugCategory: This is a bug.Category: This is a bug.F-f16_and_f128`#![feature(f16)]`, `#![feature(f128)]``#![feature(f16)]`, `#![feature(f128)]`O-x86_32Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)Target: x86 processors, 32 bit (like i686-*) (also known as IA-32, i386, i586, i686)S-waiting-on-LLVMStatus: the compiler-dragon is eepy, can someone get it some tea?Status: the compiler-dragon is eepy, can someone get it some tea?
Type
Projects
Milestone
Relationships
Development
Select code repository
Activity
[-]x86-32 "f16" ABI needs SSE[/-][+]x86-32 "f16" ABI needs SSE, incompatible with i586 targets[/+]beetrees commentedon Oct 17, 2024
I think this will require LLVM changes to properly fix, as
f16
is used as the return value of builtins; this is especially apparent when when combined with#[target_feature(enable = "sse2")]
, like in this example. LLVM will use whatever target features a function has to decide which ABI to use for a builtin, meaning that theno_sse
function presumes that the result of__truncdfhf2
has been returned inax
whereas theyes_sse2
function presumes that the result has been returned inxmm0
.A similar issue can occur on PowerPC targets with
f128
and thevsx
feature (cc #125109). Although#[target_feature(enable = "vsx")]
is still unstable, this is still an issue if user code is compiled with-Ctarget-feature=+vsx
butcompiler-builtins
is not (or the other way around: systemf128
builtins are compiled withvsx
enabled as Clang and GCC don't support_Float128
/__float128
whenvsx
is disabled).RalfJung commentedon Oct 17, 2024
Oh lol so LLVM inserts calls to builtins that use the wrong ABI? Yeah that sounds like an LLVM bug. Could you file an issue there? You probably are better at explaining the problem in their terms. :)
tgross35 commentedon Oct 17, 2024
I have been thinking that is would probably be in our advantage to just submit MRs against the ABIs whenever there are ambiguities like this. LLVM seems to usually pass
f16
andf128
in vector registers if available (and large enough forf128
), otherwise pass it as the same-sized int - but it would be good to start codifying this where applicable, considering we support these types on far more targets than C (unstably of course).__float128
/_Float128
really isn't available outside of popular 64-bit targets.RalfJung commentedon Oct 17, 2024
tgross35 commentedon Oct 17, 2024
What would be the silent part? I was mostly suggesting that the ABIs should specify a concrete calling convention for primitives when their usual cc is feature-dependent (either via other registers or indirect). Which doesn't help us with the "target features change ABI" issue, but does help us with the "is our
extern "C"
correct" concern.RalfJung commentedon Oct 18, 2024
The silent part is where using
-Ctarget-feature
is not expected to change the ABI. Code with arbitrary combinations of target features for the same target should generally be linkable with each other; any change in ABI should be explicitly requested via different flags. Also see #116344, #116558.For "Rust" we can just define our own ABI in a consistent way -- we already special case f32/f64 returning on x86-32, we should just extend the logic here to the remaining float types.
For non-"Rust" ABI however, we have two options:
f16
-returningextern "C"
functions when the SSE regs are missing@beetrees btw you said this is about
sse2
, but shouldn'tsse
be enough as that's the feature controlling the registers?beetrees commentedon Oct 18, 2024
I've filed an LLVM issue at llvm/llvm-project#112885.
AFAIK it should be, but LLVM currently switches to returning in
eax
as soon assse2
is disabled. I've filed an LLVM issue about it at llvm/llvm-project#112890.23 remaining items