Fixing this after @foad reported that the oneuse restriction regressed some code. I couldn't reproduce this without essentially disabling reassociation since that ends up optimizing the test case anyway.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
does this fix your internal regression?
Yes, thanks a lot.
FWIW, the “internal regression” is D103326, all the test changes there were gone after I rebased it upon D105069.
There is now only a single case, where slightly worse code than is generated compared to before D105069: https://github.com/llvm/llvm-project/blob/c282d55a38577e076b48cd7a8113e5eb0a2039cd/llvm/test/CodeGen/AMDGPU/GlobalISel/extractelement.ll#L4151-L4164
isLegalAddressingMode correctly returns false and the dead loads from the <64 x i32> load (which are multiple users of the G_PTR_ADD) are only removed later, after the G_PTR_ADD has long been converted to pseudo instructions. I guess there’s not much we can do about that.
Thinking more about it, maybe it makes sense to only skip the combine if isLegalAddressingMode(MaybeImm2Val->Value) && !isLegalAddressingMode(CombinedImm)?
(That should also fix the case I mentioned in the last comment.)
Add check that addressing mode was legal before, but is not legal anymore after adding the offsets.
llvm/test/CodeGen/AArch64/GlobalISel/combine-ptradd-reassociation.mir | ||
---|---|---|
26–27 ↗ | (On Diff #362739) | I think this test is actually wrong, not sure how it slipped through. To properly test the reassociation behavior we should use a legal offset. Can you replace the 4777 with 1600 and the 6 with 3? |
176–177 ↗ | (On Diff #362739) | Same here. |
Hope you don't mind me taking back this revision to address my comments and commit it.
Also, we now have the GLoadStore wrapper class that can be used here with a dyn_cast.