Support for splitting exception handling pads was added in D73739. This
change updates the code to split out exception handling pads if profile
information indicates that they are cold.
Details
- Reviewers
rahmanl - Commits
- rG2c7077e67dc7: [CodeGen] Split out cold exception handling pads.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Event Timeline
Wouldn't this cause an error when we have both hot and cold eh pads? We must ensure that same section id is assigned to all landing pads (please refer to BasicBlockSections.cpp::assignSections.
Extend the check to account of multiple landing pads with difference in hotness.
Add a new test to verify the expected behaviour.
Yes, this would cause an issue if we had hot and cold landing pads. I've updated the logic to account for this and added a test. PTAL, thanks!
I tried this patch on an instrumented build of mysql server. With this patch, an additional 28KB of text is split out from hot functions, a small but non-trivial improvement considering the size of the .text.hot section is ~1MB.
Thanks.
LGTM with minor nits.
llvm/lib/CodeGen/MachineFunctionSplitter.cpp | ||
---|---|---|
138 | "Use auto & for values and auto * for pointers unless you need to make a copy." | |
143 | Same as above. | |
llvm/test/CodeGen/X86/machine-function-splitter.ll | ||
206 | nit: You can reuse this for the previous test case (the case where all landing pads are cold). You can still have two landing pads and make one of them configurable with a macro. hot: %2 = call i32 @bar() invoke void @_Z1fv() to label %exit unwind label %lpad2, !prof ![[PROF]] Just a suggestion. Using macros could make tests less readable too. |
Thanks for the review.
llvm/test/CodeGen/X86/machine-function-splitter.ll | ||
---|---|---|
206 | It's an interesting idea but I had a couple of concerns so I left it as is
|
llvm/test/CodeGen/X86/machine-function-splitter.ll | ||
---|---|---|
206 | SGTM. Thanks for considering. |
"Use auto & for values and auto * for pointers unless you need to make a copy."
You might as well consider spelling out the type here since the type is not really obvious from this line.