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.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
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. |
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. |
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? |
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? |
Update with review comments. Do not generate a new GEP if it's okay to use the existing address.
Are bitcasts and GEPs the only possibilities here? stripAndAccumulateConstantOffsets can also handle addrspacecast and call instructions (and maybe other things in the future).