Missed optimization for switches using getelementptr

[OutOfCache]

This example is a simplified version from a case we encountered:
https://godbolt.org/z/af5oWYMzj

We can optimize the switch away by replacing the getelementptrs with the merge.geps in the merge blocks (since #156477 and #158242):
https://godbolt.org/z/MoMnbhM5d

InstCombinePHI can do just that with foldPHIArgGEPIntoPHI

llvm-project/llvm/lib/Transforms/InstCombine/InstCombinePHI.cpp

Line 535 in 06c8ee6

Instruction *InstCombinerImpl::foldPHIArgGEPIntoPHI(PHINode &PN) {

.
However, in this case the transform fails because:

1. There are multiple users
2. The offsets are constant

Both cases prevent the transform due to pessimization. Aborting on constant indices ensures phis into structs do not introduce invalid getelementptrs. Maybe we could relax this restriction on non-struct phis but the multiple users restriction still blocks optimizing our case.

What is the best way to optimize this case? Can we extend foldPHIArgGEPIntoPHi in InstCombine or should we implement this in SimplifyCFG?

Edit 12-01: Further simplified example to have the same switch condition in both switches.

[dtcxzyw]

Since the second switch uses the same condition and cases as the first one, we can replace all uses of %phi.1 with %phi.0. Then the one-use constraint can be met. https://godbolt.org/z/Wjz8jqGoW

[OutOfCache]

Good point. The incoming values are the same, as well as the switch condition, but the incoming BBs are not identical (in value, even if they are identical in content). Should this be handled by CSE, GVN or perhaps somewhere different?

[dtcxzyw]

I'd suggest implementing this in EarlyCSE. We have CallValue/GEPValue for other similar special cases. We can add something like LUTValue, which records the condition and case->value mapping.

[OutOfCache]

Alright, thank you! I will look into it. Regarding the constant int condition, can we relax it for non-struct geps or do we need a different approach?