Comments (12)
We decided that it would likely be fine (especially given firefox results) to go ahead with the change, and potentially reconsider if we get significant feedback once the change rolls out. I will be working on drafting a blog post (probably for inside rust, but maybe even the main blog, not yet clear) announcing the change and describing what it does and what impact we expect it to have.
from compiler-team.
It would be nice to have an option to disable TrapUnreachable, for applications that need to squeeze out every last extraneous byte.
from compiler-team.
The PR implementing this change uncovered that while the implementation gated behind -Zinsert-sideeffect
does work, it has a large performance regression for compile times. This is likely due to generating tons of side effect calls (at least one per function entry), which LLVM today also does not collapse into one after inlining. That generates horribly bloated IR, likely slowing down LLVM passes: rust-lang/rust#68402 (comment).
I believe that the compile time regression is not because rustc itself is slower, i.e., there is still little to no runtime effect. However, I don't think we can land the patch as-is -- asking everyone to pay 5-30% worse compile times for a relatively edge case UB mitigation is probably not tenable, particularly as it feels like there should be better options out there.
I believe it's worth discussing what approach we want to take here. There's some discussion on rust-lang/rust#68402, too, that is plausibly worth reading.
I believe that in order to be 100% sure that the UB problem is solved, we essentially need to emit this number of side effect calls. If we start to try and narrow that down while still preserving all cases, I think we're going to end up in a situation where we're basically just reimplementing LLVM (i.e., we need to always keep up with its optimizations). Now, of course, the more pessimistic we are, the less work there is, but also compile times are worse.
Based on that, it's my impression that it would be worth landing some basic mitigations in the near term. In particular, I would suggest that we make sure the trivial loop {}
case compiles correctly via side effect, but do not try to do more than that initially.
I think fully resolving the bug (rust-lang/rust#28728) will need upstream LLVM changes as I believe have been suggested, though not implemented, which enable rustc to tell LLVM that Rust functions do not have forward progress guarantees.
I think the design meeting, or whatever process we choose, is going to primarily have to answer these questions:
- How much of a compile time hit are we willing to eat in favor of soundness?
- e.g., the function-local variant of the patch regresses only 3-7%.
- Do we want to dedicate developer resources to a global analysis that aims to clean up the side effects we emit at function boundaries? Are we okay with such a global analysis?
I am not sure myself that a design meeting is the best way to do this, but I also think that we're unlikely to find the time to answer these questions without such a meeting.
from compiler-team.
Discussed in today's design meeting. We opted not to schedule this but instead:
- to merge the PR with a
-Z
flag - and to get some measurements from real-world applications
- @michaelwoerister will measure impact on FF
- @nikomatsakis will find someone to measure impact on some async-related applications
from compiler-team.
Discussed again. The PR has landed, but we've not gathered the follow-up data we meant to. We decided to try and force ourselves a bit into action. The plan is to enable this by default in ~1 month, but we have a bit of time to do some measurements beforehand.
One strategy for landing would be to keep the -Z
flag for some time but have it be used to restore the old behavior, to help make it easier to do measurements.
from compiler-team.
Unless I messed something up in my tests, the change does not seem to have any real affect on Firefox performance:
https://treeherder.mozilla.org/perf.html#/compare?originalProject=try&originalRevision=2b9e4386bfc5de74883781a869b95521e5a36290&newProject=try&newRevision=9e5d8cb0607a10a3645d5d4ac79f2df9864d41d7&framework=1
from compiler-team.
Does this mean that we can now disable the use of TrapUnreachable in LLVM? (#45920)
from compiler-team.
TrapUnreachable
also functions as a mitigation for programs that fall off the end of a function due to legitimate UB in the program, so I don't think fixing infinite loops means we can/should just disable TrapUnreachable
.
from compiler-team.
This discussion should probably take place on rust-lang/rust#68402 or in some other context.
from compiler-team.
Based on that, it's my impression that it would be worth landing some basic mitigations in the near term. In particular, I would suggest that we make sure the trivial loop {} case compiles correctly via side effect, but do not try to do more than that initially.
I'm curious whether you considered the case of a function that directly calls itself? This is the only case that's actually bitten me in practice, and it's fairly easy to do (in particular, there are times when one wants a wrapper that goes from e.g. an impl on &T
to an impl
on T
, and you wind up writing something like (**self).method()
, and if you get the number of *
wrong, you're in trouble; this is precisely why I now write T::method(self, ...)
to avoid this kind of error, but not everyone has that practice).
EDIT: That said, I really don't want to be having long conversations on these threads, we should probably move this to some other forum (e.g. Zulip)
from compiler-team.
We discussed this in our planning meeting today. The conclusion was that scheduling a meeting on this would not yet be productive, but that a good next step would be to draft a blog post summarizing:
- What is the problem
- What efforts have been done to resolve it
- What is the impact of those efforts on compillation time
which we can then use to circulate amongst LLVM devs and try to get some ideas for better directions, and/or at least capture the status of our efforts. @Mark-Simulacrum has volunteered to try and draft that post. 🎉
from compiler-team.
In the planning meeting today we decided to close this meeting proposal for now. We don't have much of an agenda or topics that still need to be discussed as a team that are specific to this issue.
from compiler-team.
Related Issues (20)
- Add Hotpatch flag HOT 1
- Promote arm64ec-pc-windows-msvc to tier 2 HOT 4
- Policy decision about v0 symbol mangling HOT 1
- `-Zfixed-x18` HOT 6
- Add a `--emit=nameres` for IDEs HOT 2
- Fully rustfmt `use` declarations HOT 17
- Project Goals Discussion
- LLVM optional target-cpu features enabled by default
- Promote loongarch64-unknown-linux-musl to tier 2 HOT 4
- Remove `src/tools/rust-demangler` HOT 3
- Extract rustc stable hasher into it's own crate HOT 3
- Enable `clang-format` for `rustc` HOT 2
- [Tracking Issue] RFC 3599 Reorganize the Compiler Team
- Contracts: Experimental attributes and language intrinsics HOT 4
- Promote wasm32-wasip2 to a Tier 2 target HOT 7
- Promote Mac Catalyst targets to Tier 2 HOT 5
- Change `-Z asm_comments` to `-Z verbose_asm`, stop stripping handwritten assembly comments HOT 4
- Remove `Nonterminal` and `TokenKind::Interpolated` HOT 3
- Add `-Z embed-source` (DWARFv5 source code embedding extension) HOT 3
- MCP: Alternate cargo freshness algorithm, unstable flag to annotate depinfo file with checksums and file sizes HOT 4
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from compiler-team.