Skip to content
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

Tracking issue for -Z emit-stack-sizes #54192

Open
japaric opened this issue Sep 13, 2018 · 5 comments
Open

Tracking issue for -Z emit-stack-sizes #54192

japaric opened this issue Sep 13, 2018 · 5 comments
Labels
A-cli Area: Command line interface to the compiler. A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. B-unstable Feature: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems

Comments

@japaric
Copy link
Member

japaric commented Sep 13, 2018

This is an experimental feature (i.e. there's no RFC for it) approved by the compiler team and added in #51946. It's available in nightly-2018-09-27 and newer nightly toolchains.

Documentation can be found in the unstable book.

@japaric japaric added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. labels Sep 13, 2018
@cramertj

This comment has been minimized.

@japaric japaric changed the title Tracking issue for -Z emit-stack-sections Tracking issue for -Z emit-stack-sizes Sep 13, 2018
@japaric

This comment has been minimized.

@jonas-schievink jonas-schievink added B-unstable Feature: Implemented in the nightly compiler and unstable. WG-embedded Working group: Embedded systems labels Nov 26, 2019
@wesleywiser wesleywiser added the S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. label Jun 24, 2022
@tgross35
Copy link
Contributor

Just curious, is there anything specific needed to eventually move this to stable? It seems like the feature is relatively simple and stable, just based on the lack of changes for the past four years

@workingjubilee
Copy link
Contributor

workingjubilee commented Mar 5, 2023

This does not offer useful support for all targets, it is unclear if it ever will, and LLVM generally seems to consider their CLI interface to be unstable to a degree we are loathe to do, so I do not think we should offer another "expose random LLVM knobs" flag without a clear plan for making it more useful and supporting it in the absence of LLVM support.

@workingjubilee workingjubilee added A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. -Zemit-stack-sizes A-cli Area: Command line interface to the compiler. labels Mar 5, 2023
@workingjubilee
Copy link
Contributor

Or e.g. "LLVM has major user orgs using this a lot, so it doesn't seem like LLVM will ever pull support for this, and LLVM has made it more useful for other targets in the past 4 years and will continue to". Or "the way this works can be eventually replaced with a few lines using object or something and not depend on a codegen backend" would also be a good answer for "why we should go ahead and stabilize this anyways"! Though the latter would raise the questions of "if we can use Rust code for this, why not just... do that, now?" and "If this is so easy to do, why does it require compiler support?"

So "how to move it along": investigate a bit further, try to anticipate future stability concerns and maybe develop a backup plan so we don't let people down in the future. Also hammer out any UX concerns, like e.g. figuring out if this should actually be a sub-option of a bigger CLI flag or something. Then bring it up to T-compiler, likely on Zulip, and discuss future moves with them.

It's hard to tell "very stable, happily used by many users in silence" apart from "fell through the cracks, works well but only in certain corner cases, is likely to bitrot and have its impl details removed the next release after its upstream LLVM implementer stops contributing". That happens when you have over 8000 open issues (of over 100 thousand total PRs and issues).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-cli Area: Command line interface to the compiler. A-LLVM Area: Code generation parts specific to LLVM. Both correctness bugs and optimization-related issues. B-unstable Feature: Implemented in the nightly compiler and unstable. C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. S-tracking-needs-summary Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. WG-embedded Working group: Embedded systems
Projects
None yet
Development

No branches or pull requests

6 participants