merge llvm.sideeffect change about compiler-team

[Mark-Simulacrum]

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.

[joshtriplett]

It would be nice to have an option to disable TrapUnreachable, for applications that need to squeeze out every last extraneous byte.

[Mark-Simulacrum]

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.

[nikomatsakis]

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

[nikomatsakis]

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.

[michaelwoerister]

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

[Amanieu]

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

[hanna-kruppe]

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.

[nikomatsakis]

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

[nikomatsakis]

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)

[nikomatsakis]

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. 🎉

[nikomatsakis]

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.