This is an archive of the discontinued LLVM Phabricator instance.

[AggressiveInstCombine] Handle the nested GEP/BitCast scenario in Load Merge.
ClosedPublic

Authored by bipmis on May 18 2023, 5:02 AM.

Details

Summary

This seems to be an issue currently where there are nested/chained GEP/BitCast Pointers. The patch bails out for such scenarios, as this is being worked upon by InstCombine to reduce to a single GEP.

Diff Detail

Event Timeline

bipmis created this revision.May 18 2023, 5:02 AM
bipmis requested review of this revision.May 18 2023, 5:02 AM
xbolva00 added inline comments.
llvm/test/Transforms/AggressiveInstCombine/AArch64/or-load.ll
2178

Typed pointers are gone, probably no new tests or fixes for them are allowed now.

@nikic ?

efriedma added inline comments.May 18 2023, 11:43 AM
llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
795

Are bitcasts and GEPs the only possibilities here? stripAndAccumulateConstantOffsets can also handle addrspacecast and call instructions (and maybe other things in the future).

llvm/test/Transforms/AggressiveInstCombine/AArch64/or-load.ll
2178

It isn't testing anything meaningful the way it's written, anyway; the pointer types are converted to "ptr" by the IR parser.

bipmis added inline comments.May 19 2023, 5:54 AM
llvm/test/Transforms/AggressiveInstCombine/AArch64/or-load.ll
2178

As specified by @xbolva00 we should not be adding test cases for typed and opague pointers. If we still agree that this should be handled I can update the patch.

efriedma added inline comments.May 19 2023, 10:35 AM
llvm/test/Transforms/AggressiveInstCombine/AArch64/or-load.ll
2178

We don't need to add tests specifically for non-opaque pointers mode (-opaque-pointers=0), no. So you can just get rid of this part of the test.

nikic added inline comments.May 19 2023, 12:40 PM
llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
795

Right, this check doesn't looks right. It does not cover all possible instructions, and it will also fail spuriously if the root pointer is a (non-constant) GEP.

I'm having a hard time following what the code here is actually trying to do, but possibly what it should be doing is to create a new GEP with the correct offset, instead of trying to reuse an existing GEP chain, and thus avoid the dominance problems that come with that?

bipmis updated this revision to Diff 524274.May 22 2023, 6:27 AM

Address review comments to generate a GEP to resolve the instruction dominance issues.

Looks like there's a failing PhaseOrdering test.

llvm/lib/Transforms/AggressiveInstCombine/AggressiveInstCombine.cpp
797–805

Maybe do something like this, so we don't unnecessarily generate a new GEP if it's okay to use the existing address?

bipmis updated this revision to Diff 524486.May 22 2023, 2:06 PM
bipmis set the repository for this revision to rG LLVM Github Monorepo.

Update with review comments. Do not generate a new GEP if it's okay to use the existing address.

nikic accepted this revision.May 23 2023, 11:45 AM

LGTM

This revision is now accepted and ready to land.May 23 2023, 11:45 AM