[LLVMdev] problem with sgt's on Sparc machine

[Christine Cheng]

Hi Venkatraman,

I am using LLVM 2.8 and llvm-gcc 4.2.

The assembly files are attached. In the assembly file, the erroneous result
is associated with 'subcc', while the correct ones are associated with 'or'.

Thanks a lot!

Christine

On Fri, Sep 16, 2011 at 2:29 PM, Venkatraman Govindaraju <
venkatra at cs.wisc.edu> wrote:

> Hello,
>
>  What is your LLVM version? Also, can you attach the assembly generated?
>
> Thanks,
> Venkatraman
>
> On Thu, Sep 15, 2011 at 5:20 PM, Bruno Cardoso Lopes
> <bruno.cardoso at gmail.com> wrote:
> > Hi,
> >
> > On Thu, Sep 15, 2011 at 3:15 PM, Christine Cheng <clcheng at stanford.edu>
> wrote:
> >> Hi guys,
> >>
> >> Thanks for the input. However, it seems that the code still produces the
> >> wrong output on a Sparc machine.
> >>
> >> My current llvm_print.bc code is:
> >>
> --------------------------------------------------------------------------------------------------
> >> ; MduleID = '<stdin>'
> >> target datalayout =
> >>
> "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-n32"
> >> target triple = "sparc-unknown-linux"
> >>
> >> @P = global i32 1
> >> @dP = global i32 1
> >>
> >> @.str = private constant [4 x i8] c"%d\0A\00", align 1
> >>
> >> define i32 @main() nounwind {
> >>
> >> entry:
> >>     %. = load i32* @P, align 4
> >>     %t1 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> >> inbounds ([4 x i8]* @.str, i32 0, i32 0), i32 %. ) nounwind
> >>     %d. = load i32* @dP, align 4
> >>     %t2 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> >> inbounds ([4 x i8]* @.str, i32 0, i32 0), i32 %d. ) nounwind
> >>     %0 = icmp sgt i32 %., 0
> >>   %1 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> inbounds
> >> ([4 x i8]* @.str, i32 0, i32 0), i1 %0 ) nounwind
> >>     %2 = icmp sgt i32 %d., 0
> >>     %3 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> >> inbounds ([4 x i8]* @.str, i32 0, i32 0), i1 %2 ) nounwind
> >>     %t3 = icmp eq i32 %d., %d.
> >>     %t4 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> >> inbounds ([4 x i8]* @.str, i32 0, i32 0), i1 %t3 ) nounwind
> >>     %4 = icmp sgt i32 1, 0
> >>     %5 = icmp sgt i32 1, 0
> >>     %6 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> >> inbounds ([4 x i8]* @.str, i32 0, i32 0), i1 %4 ) nounwind
> >>     %7 = tail call i32 (i8*, ...)* @printf(i8* noalias getelementptr
> >> inbounds ([4 x i8]* @.str, i32 0, i32 0), i1 %5 ) nounwind
> >>   ret i32 undef
> >> }
> >>
> >> declare i32 @printf(i8* nocapture, ...) nounwind
> >>
> >>
> --------------------------------------------------------------------------------------------------
> >>
> >> The output is still:
> >>
> >> 1
> >> 1
> >> 0
> >> 0
> >> 1
> >> 1
> >> 1
> >>
> >> which should be all ones. Is there a sign error somewhere?
> >
> > Please file a bug to llvm.org/bugs
> > I don't know of anyone working on Sparc right now, so if you could dig
> > and find out what llvm is generating wrong, someone may provide a fix
> > faster. Or if you're willing to right a patch that would be even
> > better! :)
> >
> > --
> > Bruno Cardoso Lopes
> > http://www.brunocardoso.cc
> >
> > _______________________________________________
> > 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/20110916/2e8c9950/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_print.bc
Type: application/octet-stream
Size: 1443 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110916/2e8c9950/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: llvm_print.s
Type: application/octet-stream
Size: 1461 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110916/2e8c9950/attachment-0001.obj>