rustc_codegen_ssa: eagerly create landing pad blocks. #84699
Conversation
rust-highfive
added
the
S-waiting-on-review
|
@bors try @rust-timer queue |
|
Awaiting bors try build completion. @rustbot label: +S-waiting-on-perf |
rustbot
added
the
S-waiting-on-perf
|
⌛ Trying commit ac3a8f9 with merge 7e27bad92f74591bb162eaff71e2f9d70a698c5f... |
|
☀️ Try build successful - checks-actions |
|
Queued 7e27bad92f74591bb162eaff71e2f9d70a698c5f with parent 10a51c0, future comparison URL. |
|
Finished benchmarking try commit (7e27bad92f74591bb162eaff71e2f9d70a698c5f): comparison url. Benchmarking this pull request likely means that it is perf-sensitive, so we're automatically marking it as not fit for rolling up. Please note that if the perf results are neutral, you should likely undo the rollup=never given below by specifying Importantly, though, if the results of this run are non-neutral do not roll this PR up -- it will mask other regressions or improvements in the roll up. @bors rollup=never |
rustbot
removed
the
S-waiting-on-perf
|
Not very clear-cut, but it does look like there are some effects. |
|
I may abandon this in favor of pursuing something based on #84771, instead - I'm really happy how that turned out. |
|
Closing as fully obsoleted by #85316. |
…nagisa rustc_codegen_ssa: generate MSVC cleanup pads on demand, like GNU landing pads. This unblocks rust-lang#84993 in terms of codegen tests, as it brings the MSVC-style (`cleanup_pad`) EH (LLVM) block order in line with the GNU-style (`landing_pad`) EH (LLVM) block order, by having both of them be on-demand (instead of MSVC-style being eager and GNU-style lazy/on-demand). It also unifies the two implementations a bit, similar to rust-lang#84699, but in the opposite direction (as that attempt made both kinds of EH pads eagerly built). ~~Opening as draft because I haven't done enough Windows testing just yet, of both this PR, and of rust-lang#84993 rebased on it.~~ (**EDIT**: seems to be working as expected) r? `@nagisa`
Since we're supported "MSVC-style" EH codegen (via
cleanup_padand funclets), we've had the analysis needed to be able to also construct "GNU-style"landing_padblocks ahead of time (like we do forcleanup_pads).The main reason not to do it eagerly is if they can get skipped often enough to reduce compile times.
(I'm hoping a perf run will be enough to reveal whether that is the case - at least this time it's not MSVC)
r? @nagisa