-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Figure out which target features affect float ABI #131799
Comments
@rust-lang/wg-llvm @bjorn3 @chorman0773 if you happen to know anything that needs to be added to the list, please let me know, or edit the issue. :) I'm mostly focusing on float ABI here; if it turns out there's a ton of architecture-specific ABI-affecting non-float features we might want to split this up into float and non-float. |
sse should be included for x86-64 and x87 should not be. Floats on 64-bit x86 use xmm registers rather than the x87 stack. |
Does |
I would assume not, they're entirely separate instruction sets and units. |
|
|
What is the default register for f16 on x86-32? I would have expected it matches f32 and f64, i.e., it uses an x87 register for returns and gets passed on the stack for arguments? Why is SSE involved at all? |
Oops, I meant returned (passed only applies for x86-64): you're correct that 32-bit x86 always passes arguments on the stack. I've updated my comment. On 32-bit x86, the ABI specifies that |
Oh wow that's Just Great. Probably justifies a separate issue: #131819 |
The context for this is #116344: some target features change the way floats are passed between functions. Changing those target features is unsound as code compiled for the same target may now use different ABIs.
In #129884 I am adding the infrastructure to have the compiler recognize this. But this infrastructure needs to be fed with information about which are the "dangerous" target features. This will have to be done for each architecture we support. (Long-term we can maybe switch this around and reject all target features except the ones that are known to be harmless, but that's a looong way off since we've just allowed arbitrary unknown LLVM features to be toggled on stable with
-Ctarget-feature
since forever.)!soft-float && x87
, so toggling either can be unsoundf16
uses SSE registers so that's extra fun, see x86-32 "f16" ABI needs SSE, incompatible with i586 targets #131819!soft-float && sse
is the relevant check!soft-float && fpregs
, so toggling either can be unsoundfp-armv8
; Rust makes-neon
imply-fp-armv8
so we have to forbid both -- butneon
is stable! See The (stable)neon
aarch64 target feature is unsound: it changes the float ABI #131058The text was updated successfully, but these errors were encountered: