This is an archive of the discontinued LLVM Phabricator instance.

Add support for GEP of GEP instruction combining when types do not exactly match
Needs ReviewPublic

Authored by simeon on Jul 31 2023, 8:37 AM.

Details

Reviewers
nikic
Summary

InstCombine can combine a GEP of a GEP into a single one if the type of the source pointer matches the source element type of the outer pointer. However, in certain cases the source pointer may have had one or more of its indices folded (as CreateGEP calls FoldGEP) and thus have a different resulting type than the source element type, leading to a missed optimization. This patch attempts to handle this case by "unfolding" the source GEP by incrementally appending zero indices until its type matches.

Diff Detail

Event Timeline

simeon created this revision.Jul 31 2023, 8:37 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 31 2023, 8:38 AM
simeon requested review of this revision.Jul 31 2023, 8:38 AM
Herald added a project: Restricted Project. · View Herald TranscriptJul 31 2023, 8:38 AM

Gentle ping

nikic added a comment.Oct 26 2023, 2:33 AM

Can you please explain what the larger context/motivation for this is?

Longer term at least, I think we would be better off going in the opposite direction and making sure that each GEP has at most one variable index. For example, if you have two GEPs with variable indices and one of them is loop invariant, LICM will be able to move it out of the loop (possibly after reassociating the two GEPs). This is not possible if both indices are in the same GEP.