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.
Details
Details
Diff Detail
Diff Detail
Event Timeline
Comment Actions
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.