-
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
Support -Cforce-frame-pointers=non-leaf
#124733
Support -Cforce-frame-pointers=non-leaf
#124733
Conversation
Some changes occurred in compiler/rustc_codegen_cranelift cc @bjorn3 These commits modify compiler targets. |
@@ -2468,6 +2468,15 @@ pub fn build_session_options(early_dcx: &mut EarlyDiagCtxt, matches: &getopts::M | |||
} | |||
} | |||
|
|||
if !nightly_options::is_unstable_enabled(matches) |
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.
Annoyingly, there seem to be multiple different ways of checking for -Zunstable-options
when implementing these ad-hoc value checks:
- Some code uses
nightly_options::is_unstable_enabled(matches)
, which parses the value independently - Some code uses
unstable_opts.unstable_options
, which uses whatever has already been parsed into theUnstableOptions
struct via normal means
In this context, we should be able to just check unstable_opts.unstable_options
, which seems like the less hacky variant.
(I assume you probably just copied this from the code immediately below. 🤷)
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.
I did check the unstable_options.unstable_options thing, but it says you shouldn't touch it directly, so I avoided poking it directly. idk lol?
I think there should be a different way of specifying "these values are unstable" that uses a pattern or pattern-guard of some kind.
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.
I realize there's only a few cases of this so it seems like a waste, but I think a profusion of flags is partly the fault of it not being easy to add such patterns that determine stability.
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.
I don’t want to derail this PR too much, but if I get a chance I’ll open a separate issue or thread to discuss improvements to unstable values of stable flags, because the status quo has been annoying me too.
compiler/rustc_session/src/config.rs
Outdated
early_dcx.early_fatal( | ||
"`-Cforce-frame-pointers=non-leaf` also requires `-Zunstable-options` \ | ||
and a nightly compiler", | ||
) |
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 we really need this? What's the concern? It's already de-facto enabled via --target=spec.json
.
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.
Target specs are also unstable.
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.
Mind, we could land it as instantly stable, I agree it has strong precedent, but then it needs to wait on a full T-compiler FCP, so "this can happen right now without requiring everyone to agree" was why I proposed doing things "correctly".
#125127 was opened which suggests "always" and "never" as other options. I think adding "always" to this is fine if there's no objection from the reviewer but I don't believe we need more options for saying "no" because "never" is even more confusing than "no" or "off" (because it is strong enough it might come off as "force frame pointers to NEVER HAPPEN!!!" which is not at all what will occur). |
d3204f4
to
f5ad116
Compare
This comment has been minimized.
This comment has been minimized.
bbd9930
to
f705368
Compare
rust-lang/compiler-team#744 was accepted. |
r? T-compiler |
I have no context about this, sorry r? compiler |
r? compiler |
r? saethlin |
Requires -Zunstable-options as this is a -C flag already.
Also lands behind -Zunstable-options, for now. Take the opportunity to do some mild cleanup.
all of these currently force stronger frame pointers, and currently the CLI does not override the target
ed9bb9f
to
c72a6ad
Compare
there... should have rebased so that the build worked again locally to start... |
@bors r=saethlin |
…ave-this, r=saethlin Support `-Cforce-frame-pointers=non-leaf` Why don't we already support this...? Suggested impl for rust-lang/compiler-team#744
💔 Test failed - checks-actions |
fuchsia... @bors r=saethlin |
☀️ Test successful - checks-actions |
Finished benchmarking commit (c3d7fb3): 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)This benchmark run did not return any relevant results for this metric. CyclesResults (secondary 2.3%)This 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 sizeResults (secondary 0.0%)This 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.
Bootstrap: 691.495s -> 693.516s (0.29%) |
Why don't we already support this...?
Suggested impl for rust-lang/compiler-team#744