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

Address CTFE perf regression introduced by #71005 #71463

Open
jonas-schievink opened this issue Apr 23, 2020 · 1 comment
Open

Address CTFE perf regression introduced by #71005 #71463

jonas-schievink opened this issue Apr 23, 2020 · 1 comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) C-enhancement Category: An issue proposing an enhancement or a PR with one. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jonas-schievink
Copy link
Contributor

In an effort to treat the return place _0 more closely to regular locals, #71005 has removed some optimizations that avoid allocating memory for locals when there's only a return place. This regresses the CTFE stress test by around 8%.

It would be good to gain the lost performance back. #71005 (comment) contains some ideas for how to do that.

@jonas-schievink jonas-schievink added C-enhancement Category: An issue proposing an enhancement or a PR with one. I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-const-eval Area: Constant evaluation (MIR interpretation) labels Apr 23, 2020
@RalfJung
Copy link
Member

RalfJung commented Apr 23, 2020

Regarding what I wrote there:

The main subtlety here is making sure this is a Miri-internal optimization that cannot be observed by the program. The fact that we reborrow the return place should exclude any observations by accessing the return place directly... so I think the only remaining possible observation is through address equality tests.

I think address equality is actually not an issue as the program cannot observe the address of the return place. There is no way to write &_0 in surface Rust. (Optimizations can introduce this but of course not in ways that are observable.)

So, yeah, that plan should be fine actually.

@workingjubilee workingjubilee added the C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such label Oct 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) C-enhancement Category: An issue proposing an enhancement or a PR with one. C-optimization Category: An issue highlighting optimization opportunities or PRs implementing such I-compiletime Issue: Problems and improvements with respect to compile times. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

3 participants