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