| a3cfdd74 | 21-May-2022 |
Rafael Auler <[email protected]> |
[BOLT] Increase coverage of shrink wrapping [5/5]
Add -experimental-shrink-wrapping flag to control when we want to move callee-saved registers even when addresses of the stack frame are captured an
[BOLT] Increase coverage of shrink wrapping [5/5]
Add -experimental-shrink-wrapping flag to control when we want to move callee-saved registers even when addresses of the stack frame are captured and used in pointer arithmetic, making it more challenging to do alias analysis to prove that we do not access optimized stack positions. This alias analysis is not yet implemented, hence, it is experimental. In practice, though, no compiler would emit code to do pointer arithmetic to access a saved callee-saved register unless there is a memory bug or we are failing to identify a callee-saved reg, so I'm not sure how useful it would be to formally prove that.
Reviewed By: Amir
Differential Revision: https://reviews.llvm.org/D126115
show more ...
|
| 3e5f67f3 | 09-Mar-2022 |
Rafael Auler <[email protected]> |
[BOLT] Increase coverage of shrink wrapping [4/5]
Change shrink-wrapping to try a priority list of save positions, instead of trying the best one and giving up if it doesn't work. This also increase
[BOLT] Increase coverage of shrink wrapping [4/5]
Change shrink-wrapping to try a priority list of save positions, instead of trying the best one and giving up if it doesn't work. This also increases coverage.
Reviewed By: Amir
Differential Revision: https://reviews.llvm.org/D126114
show more ...
|
| 3508ced6 | 21-May-2022 |
Rafael Auler <[email protected]> |
[BOLT] Increase coverage of shrink wrapping [2/5]
Refactor isStackAccess() to reflect updates by D126116. Now we only handle simple stack accesses and delegate the rest of the cases to getMemDataSiz
[BOLT] Increase coverage of shrink wrapping [2/5]
Refactor isStackAccess() to reflect updates by D126116. Now we only handle simple stack accesses and delegate the rest of the cases to getMemDataSize.
Reviewed By: Amir
Differential Revision: https://reviews.llvm.org/D126112
show more ...
|
| 72283710 | 08-Jul-2022 |
spupyrev <[email protected]> |
[BOLT] Do not merge cold and hot chains of basic blocks
There is a post-processing in ext-tsp block reordering that merges some blocks into chains. This allows to maintain the original block order i
[BOLT] Do not merge cold and hot chains of basic blocks
There is a post-processing in ext-tsp block reordering that merges some blocks into chains. This allows to maintain the original block order in the absense of profile data and can be beneficial for code size (when fallthroughs are merged). In the earlier version we could merge hot and cold (with zero execution count) chains, that later were split by SplitFunction.cpp (when split-all-cold=1). The diff eliminates the redundant merging.
It is unlikely the change will affect the performance of a binary in a measurable way, as it is mostly operates with cold basic blocks. However, after the diff the impact of split-all-cold is almost negligible and we can avoid the extra function splitting.
Measuring on the clang binary (negative is good, positive is a regression): **clang12** benchmark1: `0.0253` benchmark2: `-0.1843` benchmark3: `0.3234` benchmark4: `0.0333`
**clang10** benchmark1 `-0.2517` benchmark2 `-0.3703` benchmark3 `-0.1186` benchmark4 `-0.3822`
**clang7** benchmark1 `0.2526` benchmark2 `0.0500` benchmark3 `0.3024` benchmark4 `-0.0489`
**Overall**: `-0.0671 ± 0.1172` (insignificant)
Reviewed By: maksfb
Differential Revision: https://reviews.llvm.org/D129397
show more ...
|