[LLVMdev] A strange testing case of SROA

[Pete Cooper]

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>