This is an archive of the discontinued LLVM Phabricator instance.

[InstCombine] Combine opaque pointer GEPs with mismatching element types
ClosedPublic

Authored by nikic on Apr 26 2022, 8:20 AM.

Details

Summary

Currently, two GEPs will only be combined if the result element type of one is the same as the source element type of the other. However, this means we may miss folding opportunities where the second GEP could be rewritten using a different element type. This is especially relevant for opaque pointers, where constant GEPs often use i8 element type.

Address this by converting GEP indices to offsets, adding them, and then converting them back to indices. The first (inner) GEP is allowed to have variable indices as well, in which case only the constant suffix is converted into an offset.

I believe this should address the regression reported in https://reviews.llvm.org/D123300#3467615.

Diff Detail

Event Timeline

nikic created this revision.Apr 26 2022, 8:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2022, 8:20 AM
nikic requested review of this revision.Apr 26 2022, 8:20 AM
Herald added a project: Restricted Project. · View Herald TranscriptApr 26 2022, 8:20 AM
nikic added inline comments.Apr 26 2022, 8:23 AM
llvm/test/Transforms/InstCombine/opaque-ptr.ll
215

Worth noting that we still miss cases like these, where we would have to change the element type of the first GEP. I think we'll want to handle this by canonicalizing constant GEPs to i8 in InstCombine. I think this patch should ensure that doing so will not cause regressions when such i8 GEPs are combined with non-constant GEPs.

Type-based GEPs are such a mess :(

nikic updated this revision to Diff 425229.Apr 26 2022, 8:39 AM

Don't require one-use for two constant GEPs, so the case from https://reviews.llvm.org/D123300#3467615 is actually fixed.

aeubanks added inline comments.
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
2067

do we want to skip the transform after this if any of this fails?

2070

I'm surprised we don't have some sort of first_n

aeubanks accepted this revision.Apr 26 2022, 11:17 AM
This revision is now accepted and ready to land.Apr 26 2022, 11:17 AM
nikic added inline comments.Apr 26 2022, 12:03 PM
llvm/lib/Transforms/InstCombine/InstructionCombining.cpp
2067

I think it's fine to skip it, because this one should always be more powerful (for the "all constant GEP" subset it handles). At least that was the intention, maybe I'm overlooking some edge case.

2070

Yeah, I went looking for that one as well. There is take_front on indexed_accessor_range, but there doesn't seem to be anything generic currently.

This revision was landed with ongoing or failed builds.Apr 27 2022, 12:36 AM
This revision was automatically updated to reflect the committed changes.