A strange testing case of SROA

Hi,

    Following is excerpted from dynamic-vector-gep.ll.
The resulting "extractelement" seems to always return 0.0f regardless the value idx1 and idx2 is holding.
Am I missing something here or there is something fishy take place?

Thanks
Shuxin

101 ; CHECK: test6
102 ; CHECK: insertelement <4 x float> zeroinitializer, float 1.000000e+00, i32 %idx1
103 ; CHECK: extractelement <4 x float> zeroinitializer, i32 %idx2
104
105 %vector.pair = type { %vector.anon, %vector.anon }
106 %vector.anon = type { %vector }
107 %vector = type { <4 x float> }
108
109 ; Dynamic GEPs on vectors were crashing when the vector was inside a struct
110 ; as the new GEP for the new alloca might not include all the indices from
111 ; the original GEP, just the indices it needs to get to the correct offset of
112 ; some type, not necessarily the dynamic vector.
113 ; This test makes sure we don't have this crash.
114 define float @test6(i32 %idx1, i32 %idx2) {
115 entry:
116 %0 = alloca %vector.pair
117 store %vector.pair zeroinitializer, %vector.pair* %0
118 %ptr1 = getelementptr %vector.pair* %0, i32 0, i32 0, i32 0, i32 0, i32 %idx1
119 store float 1.0, float* %ptr1
120 %ptr2 = getelementptr %vector.pair* %0, i32 0, i32 1, i32 0, i32 0, i32 %idx2
121 %ret = load float* %ptr2
122 ret float %ret
123 }

Hi Shuxin

I think i might have written that test. And yeah, no matter what values you get you’ll get a 0.0. Its probably a bad test case, but i can’t remember if it exposed a bug in this form or not. Since writing it Chandler rewrote SROA anyway so the original bug is long gone.

Thanks,
Pete

Hi, Pete:

Thank you for the clarification. Yes, it will incur bug if idx1 == idx2. This opt (try to promote
vector-element-insertion/extraction) also incur miscompilation in other applications. I have to
disable this optimization, at least, for the time being.

Thanks
Shuxin

Hi Shuxin,

    Following is excerpted from dynamic-vector-gep.ll.
The resulting "extractelement" seems to always return 0.0f regardless the value
idx1 and idx2 is holding.
Am I missing something here or there is something fishy take place?

maybe this is the same as PR15674.

Ciao, Duncan.

Hi, Duncan:

    Thank you for sharing this info. I will check and go back to you next Monday.
In case PR15674 is caused by the same bug, I will put a comment over there and close it.

Thank you again!
Shuxin

Hi, Duncan:

    As r178974 suggests, PR15674 is caused by another bug of SROA.

Thanks
Shuxin