Using profile information to guide consthoisting is generally helpful for performance, so we want to turn it on by default. No compile time or perf regression were found using spec2000 and spec2006 on x86. Some significant improvement (>20%) was seen on internal benchmarks.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
test/CodeGen/X86/fold-tied-op.ll | ||
---|---|---|
10 ↗ | (On Diff #105450) | After BFI based const hoisting enabled, some const is not hoisted to func entry. This will change live range and affect scheduling for live range shrinking (https://reviews.llvm.org/D32563). |
test/Transforms/ConstantHoisting/X86/ehpad.ll | ||
4 ↗ | (On Diff #105450) | The bitcast is used for const 9209618997431186100. Now the bitcast is inserted in catchpad block when consthoist-with-block-frequency is enabled so the FIXME can be removed. |
test/CodeGen/X86/fold-tied-op.ll | ||
---|---|---|
10 ↗ | (On Diff #105450) | Can you add profile annotation so that the test behavior does not change? |
test/CodeGen/X86/fold-tied-op.ll | ||
---|---|---|
10 ↗ | (On Diff #105450) | Adding profile annotation doesn't change the result. Currently BFI based const hoisting only hoists the const when the freq of the target bb is colder, so for case like "if(cond) then use constA; else use constA", although constA is used both in then and else branch, it will not be hoisted before if(cond) because the freq doesn't change after the hoisting. |
test/CodeGen/X86/fold-tied-op.ll | ||
---|---|---|
10 ↗ | (On Diff #105450) | If the frequency is equal, should it be hoisted (as it reduces size at least)? |
test/CodeGen/X86/fold-tied-op.ll | ||
---|---|---|
10 ↗ | (On Diff #105450) | Yes, I can do that in a separate patch. |