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 On Apr 5, 2013, at 11:57 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote:> 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 } > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130405/a5ecd127/attachment.html>
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
On 4/5/13 4:10 PM, Pete Cooper wrote:> 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
> On Apr 5, 2013, at 11:57 AM, Shuxin Yang <shuxin.llvm at gmail.com
> <mailto:shuxin.llvm at gmail.com>> wrote:
>
>> 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 }
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu
>> <mailto:LLVMdev at cs.uiuc.edu>http://llvm.cs.uiuc.edu
>> <http://llvm.cs.uiuc.edu/>
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130405/98f22262/attachment.html>
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
On 4/6/13 2:55 AM, Duncan Sands wrote:> 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.
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev