In tryBitfieldInsertOpFromOr, if the new created LSR Node's source is LSR with Imm shift, try to fold them into one LSR.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It looks like the lsr+bfi is coming out of tryBitfieldInsertOpFromOr in AArch64ISelDAGToDAG.cpp. I see two possible alternatives:
- Enhance tryBitfieldInsertOpFromOr to detect when it's shifting a shift.
- Form the BFM op as a DAGCombine, instead of waiting for isel.
This MI peephole seems unlikely to be useful outside of this one case, so I think I'd prefer to fix the existing logic.
For now test case's selection DAG before instruction select is:
t0: ch = EntryToken t2: i32,ch = CopyFromReg t0, Register:i32 %0 t7: i32 = srl t2, Constant:i64<16> t9: i32 = and t7, Constant:i32<240> t4: i32 = and t2, Constant:i32<-241> t10: i32 = or t9, t4 t12: ch,glue = CopyToReg t0, Register:i32 $w0, t10 t13: ch = AArch64ISD::RET_FLAG t12, Register:i32 $w0, t12:1
Do you mean we add a new AArch64ISD like AArch64ISD::BFM, then form AArch64ISD::BFM in performOrCombine ?
@efriedma is the new patch match solution 1?
And if possible can you help to explain solution 2?
I'm a beginner on llvm so it will be grateful if you can tell me the detail solution.
Yes, this is my "solution 1". "Solution 2" would be defining AArch64ISD::BFM, and moving all the code from tryBitfieldInsertOpFromOr into a DAGCombine. The advantage of that is that we can perform general DAGCombine optimizations afterwards, not just this specific one. The disadvantage is that you have to be careful not to block other optimizations. (And it's more work to modify the current code.)
@benshi001 any further thoughts?
I have no commit access so can someone help me to check in the code ?
name: chenglin.bi
email: chenglin.bi@cixcomputing.com
https://github.com/llvm/llvm-project/commit/87f0d55304a27ce0f6178eed65d8dad49b5dcfd9
You need to add your working email to your github account, to show your commit properly.