Clean up a TODO, to support folding a shift of a constant by a select of constants, on targets with different shift operand sizes.
Details
- Reviewers
craig.topper lebedev.ri spatel RKSimon nemanjai amyk - Group Reviewers
Restricted Project - Commits
- rG385e9a2a047b: [DAGCombiner] Improve shift by select of constant
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
llvm/test/CodeGen/PowerPC/select_const.ll | ||
---|---|---|
630 | any ideas on these regressions? |
llvm/test/CodeGen/PowerPC/select_const.ll | ||
---|---|---|
630 |
Forgive me, I'm not very familiar with PowerPC, but is this actually worse? It now looks just like the above unaltered test for select of constants shifted by constant. If it is worse, should we change that as well? |
llvm/test/CodeGen/PowerPC/select_const.ll | ||
---|---|---|
630 | It looks good to me as before the change, clrlwi, subfic and slw are chained together, while the new one only chain two instructions.(andi. and iselgt) And they didn't have too much latency difference AFAIK. But please correct me if I miss something here. |
llvm/test/CodeGen/PowerPC/select_const.ll | ||
---|---|---|
630 | Agree, my pfm test shows that using isel here is better. |
I am really sorry that I've missed these notifications. The PPC changes are perfectly fine. This might lead to regressions if the shift amount is large enough to require more than a single instruction to produce each constant (i.e. the constant no longer fits in a 16-bit signed immediate). But there's work underway to improve constant materialization in the back end that will alleviate this problem.
So LGTM and sorry about the delay.
Thank you everyone for looking at this! Could one of you please commit this for me? Layton Kifer <laytonkifer@gmail.com>
any ideas on these regressions?