similar to: [LLVMdev] problem with sgt's on Sparc machine

Hi, > 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" if you are using this target data layout and triple on a Sparc machine, I'm not surprised you get wrong results. Ciao, Duncan. > > @P = global i32 1 > @dP =

Hi Duncan, Thanks for the reply! There is no LLVM on the Sparc machine so I cannot compile my code there into .s file. How shall I modify the target data layout and triple so it works on Sparc? Basically I got these from compiling C code using llvm-gcc. Best, Christine On Thu, Sep 15, 2011 at 10:20 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi, > > > target datalayout =

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 =

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

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 =

On Thu, Sep 15, 2011 at 11:06 AM, Christine Cheng <clcheng at stanford.edu> wrote: > Hi Duncan, > > Thanks for the reply! There is no LLVM on the Sparc machine so I cannot > compile my code there into .s file. How shall I modify the target data > layout and triple so it works on Sparc? Basically I got these from compiling > C code using llvm-gcc. You can use clang for

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?

Hi Duncan, A DragonEgg/GCC-related question: do you know where these strange FRAME tokens originate from (e.g. %struct.FRAME.matmul)? Compiling simple Fortran code with DragonEgg: > cat matmul.f90 subroutine matmul(nx, ny, nz) implicit none integer :: nx, ny, nz real, dimension(nx, ny) :: A real, dimension(ny, nz) :: B real, dimension(nx, nz) :: C integer :: i, j, k real,

Le 29 mai 2010 à 01:08, Bill Wendling a écrit : > Hi Stéphane, > > The SSE support is the LLVM backend is fine. What is the code that's generated? Do you have some short examples of where LLVM doesn't do as well as the equivalent scalar code? > > -bw > > On May 28, 2010, at 12:13 PM, Stéphane Letz wrote: We are actually testing LLVM for the Faust language

On Sat, May 29, 2010 at 12:42 AM, Stéphane Letz <letz at grame.fr> wrote: > > Le 29 mai 2010 à 01:08, Bill Wendling a écrit : > >> Hi Stéphane, >> >> The SSE support is the LLVM backend is fine. What is the code that's generated? Do you have some short examples of where LLVM doesn't do as well as the equivalent scalar code? >> >> -bw >>

Hello, while writing a new LLVM backend I have observed that in some cases the optimizer produces an "icmp sgt i32 %a, 0" where I would have expected an "icmp ugt i32 %a, 0". For example when I feed "opt -O3 -S ..." (LLVM 2.9, Windows) with ------------------------------------------------------------------------ target datalayout = "E-p:32:32:32"

Dear all, I'm currently working on the automated program analysis tool AProVE (http://aprove.informatik.rwth-aachen.de/) and would like to use LLVM for analysis of C programs. I have the following example C program dealing with simple lists of integers: ------------ start C example ------------- #include<stdlib.h> struct list_el { int val; struct list_el * next; }; typedef

On Sat, May 29, 2010 at 1:18 AM, Eli Friedman <eli.friedman at gmail.com> wrote: > On Sat, May 29, 2010 at 12:42 AM, Stéphane Letz <letz at grame.fr> wrote: >> >> Le 29 mai 2010 à 01:08, Bill Wendling a écrit : >> >>> Hi Stéphane, >>> >>> The SSE support is the LLVM backend is fine. What is the code that's generated? Do you have some

Icmp sgt is correct. Note that "ugt x, 0" is the same as "x != 0" which is not what you want. -Chris On Aug 1, 2011, at 9:11 AM, Jonas Gefele <llvm.org at schrieb.de> wrote: > Hello, > > while writing a new LLVM backend I have observed that in some cases the > optimizer produces an "icmp sgt i32 %a, 0" where I would have expected an >

Hi, I am observing a strange behaviour in which Clang ignores __restirct when I include some standard headers. For example, this code: void vec_add(int* __restrict a, int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } results in: ; Function Attrs: nofree norecurse nounwind define dso_local void @_Z7vec_addPiS_i(i32*

I am trying a setup where the one loop is rewritten as two loops. This avoids the 'rem' and 'div' instructions in the index calculation (which give the loop vectorizer a hard time). However, with this setup the loop vectorizer complains about a too small loop. LV: Checking a loop in "main" LV: Found a loop: L3 LV: Found a loop with a very small trip count. This loop

Hi Christine, > I am using LLVM 2.8 and llvm-gcc 4.2. Could you please try svn top-of-tree? Clang is also a better choice here. > The assembly files are attached. In the assembly file, the erroneous result > is associated with 'subcc', while the correct ones are associated with 'or'. -- Bruno Cardoso Lopes http://www.brunocardoso.cc

On 07/04/2013 01:39 PM, Stéphane Letz wrote: > Hi, > > Our DSL can generate C or directly generate LLVM IR. With LLVM 3.3, we can vectorize the C produced code using clang with -O3, or clang with -O1 then opt -O3 -vectorize-loops. But the same program generating LLVM IR version cannot be vectorized with opt -O3 -vectorize-loops. So our guess is that our generated LLVM IR lacks some

I can't reproduce this problem with the recent svn trunk. LLVM 2.9 has lots of fixes for Sparc back-end. So, please at least try with LLVM-2.9. Thanks, On Fri, Sep 16, 2011 at 6:30 PM, Bruno Cardoso Lopes <bruno.cardoso at gmail.com> wrote: > Hi Christine, > >> I am using LLVM 2.8 and llvm-gcc 4.2. > > Could you please try svn top-of-tree? Clang is also a better

In the case when coming from C it was probably the loop unroller and SLP vectorizer which vectorized the code. Potentially I could do the same in the IR. However, the loop body that is generated in the IR can get very large. Thus, the loop unroller will refuse to unroll the loop in a large number of (important) cases. Isn't there a way to convince the loop vectorizer that it should