-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Use preserve_mostcc
for extern "rust-cold"
#115260
Conversation
As experimentation in 115242 has shown looks better than `coldcc`. And *don't* use a different convention for cold on Windows, because that actually ends up making things worse. cc tracking issue 97544
(rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 These commits modify compiler targets. |
@@ -39,7 +39,7 @@ fn clif_sig_from_fn_abi<'tcx>( | |||
pub(crate) fn conv_to_call_conv(sess: &Session, c: Conv, default_call_conv: CallConv) -> CallConv { | |||
match c { | |||
Conv::Rust | Conv::C => default_call_conv, | |||
Conv::RustCold => CallConv::Cold, | |||
Conv::Cold | Conv::PreserveMost | Conv::PreserveAll => CallConv::Cold, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
None of these are ABI compatible between LLVM and Cranelift actually. So using them in the standard library will break ABI compatibility. It should be possible to implement in Cranelift if LLVM guarantees a specific call conv for them, but that doesn't help for GCC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, I guess that's not a blocker for this PR, though, since it was coldcc
before, which if I understand correctly already wasn't ABI compatible.
What's your meta expectation here for the future? Do all extern
s have to be interoperable between backends? That would seem a shame, as it would essentially force extern "Rust"
to always be the same as extern "C"
, rather than letting a backend innovate something faster. Would it be ok to have options to force rust-cold
to be something else (maybe just C
) for people who need the interop?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do all externs have to be interoperable between backends?
Preferably, but if any is not interoperable, denying usage in the standard library and emitting a hard error if caller and callee are compiled with a different codegen backend would work too I guess. (eg by internally lowering it to a different call conv depending on the selected codegen backend before we do typeck)
That would seem a shame, as it would essentially force extern "Rust" to always be the same as extern "C", rather than letting a backend innovate something faster.
extern "Rust"
could be changed to internally use eg extern "sysv"
on all targets or extern "win64"
on all x86_64 targets. Note that extern "Rust"
is already not extern "C"
. The lowering from rust types to primitives is different, but those primitives are passed in the same way such that it is actually possible for all backends to use the same ABI by reusing the lowering code in rustc_target. I don't want to change that.
Would it be ok to have options to force rust-cold to be something else (maybe just C) for people who need the interop?
That wouldn't help if the standard library uses it as the LLVM compiled standard library will be used with cg_clif once it ships on nightly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes look good to me. It looks like cranelift/llvm ABI mismatch is an existing issue and should be addressed separately (could someone make sure we track this somewhere?), if this is indeed the case — r=me.
Yes, I think this PR is still good progress -- thinks like moving the abi-vs-conv translation point to a better place, for example -- and since it's not used anywhere, it's ok if it's not quite usable in general just yet. I've added an Unresolved Question to the tracking issue for @bors r=WaffleLapkin |
⌛ Testing commit 754f488 with merge a069e3f9c84eaff5d70655447602974f15124d27... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors retry |
⌛ Testing commit 754f488 with merge 59c2f8a62fef237eb5335173439fecf6a06e8793... |
💔 Test failed - checks-actions |
The job Click to see the possible cause of the failure (guessed by this bot)
|
@bors retry (curl: (6) Could not resolve host: static.rust-lang.org) |
☀️ Test successful - checks-actions |
Finished benchmarking commit (f3284dc): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 630.211s -> 631.106s (0.14%) |
As experimentation in #115242 has shown looks better than
coldcc
. Notably, clang exposespreserve_most
(https://clang.llvm.org/docs/AttributeReference.html#preserve-most) but notcold
, so this change should put us on a better-supported path.And don't use a different convention for cold on Windows, because that actually ends up making things worse. (See comment in the code.)
cc tracking issue #97544