GithubHelp home page GithubHelp logo

Comments (12)

Mark-Simulacrum avatar Mark-Simulacrum commented on July 30, 2024 2

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.

joshtriplett avatar joshtriplett commented on July 30, 2024 1

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.

Mark-Simulacrum avatar Mark-Simulacrum commented on July 30, 2024 1

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.

nikomatsakis avatar nikomatsakis commented on July 30, 2024

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

from compiler-team.

nikomatsakis avatar nikomatsakis commented on July 30, 2024

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.

michaelwoerister avatar michaelwoerister commented on July 30, 2024

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.

Amanieu avatar Amanieu commented on July 30, 2024

Does this mean that we can now disable the use of TrapUnreachable in LLVM? (#45920)

from compiler-team.

hanna-kruppe avatar hanna-kruppe commented on July 30, 2024

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.

nikomatsakis avatar nikomatsakis commented on July 30, 2024

This discussion should probably take place on rust-lang/rust#68402 or in some other context.

from compiler-team.

nikomatsakis avatar nikomatsakis commented on July 30, 2024

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.

nikomatsakis avatar nikomatsakis commented on July 30, 2024

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.

nikomatsakis avatar nikomatsakis commented on July 30, 2024

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)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo 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.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.