LongVectorLowering and ThreeElementVectorLowering don't handle constexpr pointers correctly
While transitioning LongVectorLowering to handle opaque pointers, I encountered an issue with the way these passes handle constexpr pointers. For example:
target datalayout = "e-p:32:32-i64:64-v16:16-v24:32-v32:32-v48:64-v96:128-v192:256-v256:256-v512:512-v1024:1024"
target triple = "spir-unknown-unknown"
@gv = internal global <8 x i32> zeroinitializer, align 32
define void @test() {
entry:
%load = load <8 x i32>, <8 x i32>* getelementptr (<8 x i32>, <8 x i32>* @gv, i32 1), align 32
%load2 = load i32, i32* getelementptr (<8 x i32>, <8 x i32>* @gv, i32 1, i32 0), align 32
ret void
}
%load is handled correctly, but %load2 is not handled because the pointer does not appear to require lowering. With opaque pointers, the easier implementation would likely also have a problem with %load too.
A potential solution might be to attempt to visit the constant pointers when the globals are handled. That is, trace users until a non-constant is encountered.
Traversing forwards doesn't lend itself to the way the pass works. A few other options:
- Convert all constantexprs to instructions. Either a separate pass or as part of these passes. This feels like a bit of a cop out, but it does avoid the problem.
- Always handle constants. This would require reworking the passes' assumptions about lowering. It likely involves more checking on whether the used values have changed.
I have just realized that #905 is part of the first solution.
Note that it is not enough to do it in the SimplifyPointerBitcast part as the inlining of function in ThreeElementVectorLoweringPass and LongVectorLoweringPass can recreate them.
It feels like this is now fixed
closing the issue. Feel free to reopen if I missed something