[LLVMdev] Is it an opt bug ?

[Seb]

Hi Duncan,

Indeed, I made same experiment as you and concluded that it might be a BUG.
Shall I submit it to llvm bug tracking support ?
Do you think there could be a work-around ?
Thanks for your quick answer.

Best Regards
Seb

2012/2/28 Duncan Sands <baldrick at free.fr>

> Hi Seb, I think it is an opt bug.  If you run opt at -O1 then you get:
>
> define void @t2(double* nocapture %x) nounwind {
> L.entry:
>    %a = alloca [2 x i64], align 8
>   %0 = getelementptr inbounds [2 x i64]* %a, i32 0, i32 0
>   store i64 3, i64* %0, align 8
>    %1 = getelementptr [2 x i64]* %a, i32 0, i32 1
>    store i64 5, i64* %1, align 8
>    %2 = bitcast [2 x i64]* %a to double*
>    %3 = load double* %2, align 8
>   store double %3, double* %x, align 4
>   %4 = load i64* %0, align 8
>   %5 = add i64 %4, 536870910
>   %6 = trunc i64 %5 to i32
>   %7 = getelementptr [2 x i64]* %a, i32 0, i32 %6
>   %8 = bitcast i64* %7 to double*
>   %9 = load double* %8, align 8
>   %10 = getelementptr double* %x, i32 1
>   store double %9, double* %10, align 4
>   ret void
> }
>
> Notice "%5 = add i64 %4, 536870910".  This is presumably trying to
> subtract 2,
> but this doesn't seem to be the same as subtracting 2 even after the
> truncate
> to 32 bits.
>
> This then causes a load from a wild stack location later.  Probably at a
> higher
> optimization level this is recognized as an undefined operation causing
> code
> after it to be removed, including the final store.
>
> Ciao, Duncan.
>
>
> On 28/02/12 14:58, Seb wrote:
> > Hi all,
> >
> > I'm looking at following code snippet:
> >
> > void t2(double *x)
> > {
> >        long long a[2];
> >        a[0] = 3;
> >        a[1] = 5;
> >        *x = * ((double *) a);
> >        *(x+1) = * ((double *) &a[a[0]-2]);
> > }
> >
> > I use generate LLVM code using my own front-end that looks like:
> >
> >
> > ; ModuleID = 'jb.c'
> > target datalayout =
> >
> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
> > target triple = "i386-pc-linux-gnu"
> > define void @t2(double* %x) {
> > L.entry:
> >      %a = alloca [2 x i64], align 4
> >
> >      %x.addr = alloca double*
> >      store double* %x, double** %x.addr
> >      %0 = bitcast [2 x i64]* %a to i64*
> >      store i64 3, i64* %0
> >      %1 = getelementptr [2 x i64]* %a, i32 0, i32 1
> >      store i64 5, i64* %1
> >      %2 = bitcast [2 x i64]* %a to double*
> >      %3 = load double* %2
> >      %4 = load double** %x.addr
> >      store double %3, double* %4
> >      %5 = bitcast [2 x i64]* %a to double*
> >      %6 = bitcast double* %5 to i8*
> >      %7 = bitcast [2 x i64]* %a to i64*
> >      %8 = load i64* %7
> >      %9 = sub i64 %8, 2
> >      %10 = trunc i64 %9 to i32
> >      %11 = mul i32 %10, 8
> >      %12 = getelementptr i8* %6, i32 %11
> >      %13 = bitcast i8* %12 to double*
> >      %14 = load double* %13
> >      %15 = load double** %x.addr
> >      %16 = bitcast double* %15 to i8*
> >      %17 = getelementptr i8* %16, i32 8
> >      %18 = bitcast i8* %17 to double*
> >      store double %14, double* %18
> >      ret void
> > }
> >
> > when I use LLVM opt on this .ll file I've got:
> >
> > ; ModuleID = 'jb.ll'
> > target datalayout =
> >
> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
> > target triple = "i386-pc-linux-gnu"
> >
> > define void @t2(double* nocapture %x) nounwind {
> > L.entry:
> >    store double 1.482197e-323, double* %x, align 4
> >    ret void
> > }
> >
> > Now if I use clang -O2 I've got following llvm file:
> >
> > ; ModuleID = 'jb.clang.ll'
> > target datalayout =
> >
> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32-n8:16:32"
> > target triple = "i386-unknown-linux-gnu"
> >
> > define void @t2(double* nocapture %x) nounwind {
> >    store double 1.482197e-323, double* %x, align 4, !tbaa !0
> >    %1 = getelementptr inbounds double* %x, i32 1
> >    store double 2.470328e-323, double* %1, align 4, !tbaa !0
> >    ret void
> > }
> >
> > !0 = metadata !{metadata !"double", metadata !1}
> > !1 = metadata !{metadata !"omnipotent char", metadata !2}
> > !2 = metadata !{metadata !"Simple C/C++ TBAA", null}
> >
> > Which is what I was expecting, to me it seems that there is a bug in
> LLVM opt,
> > is it the case ?
> >
> > Thanks for your answer
> > Best Regards
> > Seb
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
> _______________________________________________
> 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/20120228/0e73a19f/attachment.html>