similar to: [LLVMdev] IntervalPartition bug?

On Fri, 29 Apr 2005, Vladimir Prus wrote: > it looks like the IntervalPartition does not work as expected when constructed > from another interval partition. > > Say, I have built an interval partition from function, and the first interval > has two basic blocks. When I create second order partition and print all > intervals, the second basic block of the function is not seen

On Saturday 30 April 2005 07:30, Chris Lattner wrote: > > Here's NodeTy is a first order interval and can contain several basic > > blocks, but we add only the first one. I attach the patch which tries to > > fixes that. Also, for convenience, there's output of 2-order interval on > > some test case. 'log' is before the change and 'log_good' is

On Mon, 21 Feb 2005, Jeff Cohen wrote: > Sorry, I thought I was running selection dag isel but I screwed up when > trying out the really big array. You're right, it does clean it up except > for the multiplication. > > So LoopStrengthReduce is not ready for prime time and doesn't actually get > used? I don't know what the status of it is. You could try it out,

On Mon, 21 Feb 2005, Jeff Cohen wrote: > I noticed that fourinarow is one of the programs in which LLVM is much slower > than GCC, so I decided to take a look and see why that is so. The program > has many loops that look like this: > > #define ROWS 6 > #define COLS 7 > > void init_board(char b[COLS][ROWS+1]) > { > int i,j; > > for

Sorry, I thought I was running selection dag isel but I screwed up when trying out the really big array. You're right, it does clean it up except for the multiplication. So LoopStrengthReduce is not ready for prime time and doesn't actually get used? I might consider whipping it into shape. Does it still have to handle getelementptr in its full generality? Chris Lattner wrote:

Hi , I got a few for writing a pass. 1) Is it possible to use input parameters in command line ? For example, we got our own pass, ie. HELLO opt -load ../../Debug/lib/libHELLO.so -HELLO < hello.bc From the above command line, could we use some input parameter and we can read those parameter in Pass routine? 2) For splitting BB, the way what I did is to pick up instruction

Because I've been doing a bit of performance work recently, and because using gprof with the C backend has some limitations, I wrote a little "llvm-prof" utility. Here's a synopsis of how to use it if you're interested: Basic usage: llvm/utils/profile.pl <program.bc> <program arguments> This instruments the bytecode file, executes it with the JIT

On Wed, 31 Mar 2004, Vladimir Prus wrote: > I've just downloaded the latest release of LLVM, and playing with the > following simple example: > > int main() > { > int r(0); > for (int i = 0; i < 100; ++i) > r += i; > ; > return r; > } When I compiled it, I got the following LLVM code: int %main() { entry: call void %__main( )

Chris Lattner wrote: > > int main() > > { > > int r(0); > > for (int i = 0; i < 100; ++i) > > r += i; > > ; > > return r; > > } > > When I compiled it, I got the following LLVM code: The code I get is somewhat different: int %main() { entry: %tmp.1.i = load bool* %Initialized.0__ ; <bool> [#uses=1] br

hi, I want to know what is exact meaning in the following code. target endian-- %struct..TorRec-- %struct.TorRec-- implementation-- ;<sbyte>[#uses=1/0]-- how to explain them in details? Does anyone give me a guide? thanks yueqiang -------------------------------------------------------------- target endian = little target pointersize = 32 %struct..TorRec = type { int, void ()* }

Hello . I ran opt with -indvars options , got wrong result.  This is my example: test.cc :  int test(int a)                 {      for (int i = 2; i < a; ++i) {                            a += ;      }              return a; } clang -O3 -emit-llvm -S test.cc -o test.ll opt -indvards -S test.ll  -o indvars.ll > /dev/null indvars.ll : ; ModuleID = 'test.ll' target datalayout =

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Thursday, July 16, 2015 1:06:03 AM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration

I noticed that fourinarow is one of the programs in which LLVM is much slower than GCC, so I decided to take a look and see why that is so. The program has many loops that look like this: #define ROWS 6 #define COLS 7 void init_board(char b[COLS][ROWS+1]) { int i,j; for (i=0;i<COLS;i++) for (j=0;j<ROWS;j++) b[i][j]='.';

Hi I have this program in which fooBuf can only take on NULL or the address of local_fooBuf, and fooBuf and local_fooBuf have scope of the foo function. Therefore there is no way for the fooPtr argument to alias with fooBuf. However, LLVM basicaa and globalsmodref-aa say the 2 pointers may alias. I am thinking whether i should implement a limited form of point-to alias on the fooBuf pointer in

----- Original Message ----- > From: "Chandler Carruth" <chandlerc at google.com> > To: "Hyojin Sung" <hsung at us.ibm.com>, llvmdev at cs.uiuc.edu > Sent: Wednesday, July 15, 2015 7:34:54 PM > Subject: Re: [LLVMdev] Improving loop vectorizer support for loops > with a volatile iteration variable > On Wed, Jul 15, 2015 at 12:55 PM Hyojin Sung

Here is original C code: void topup(int a[], unsigned long i) { for (; i < 16; i++) { a[i] = 1; } } Here is the IR before the pass where I expect SCEV to return trip-count value ; Function Attrs: nofree norecurse nounwind uwtable writeonly define dso_local void @topup(i32* nocapture %a, i64 %i) local_unnamed_addr #0 { entry: %cmp3 = icmp ult i64 %i, 16 br i1

Which cases does this pass handle which aren't otherwise optimized out by passes like GlobalValueNumbering or DeadCodeElimination? Thanks, Jake VanAdrighem On Thu, Sep 10, 2015 at 2:35 PM, Steve King <steve at metrokings.com> wrote: > Hello LLVM, > It seems this thread has gone cold. Is there some low risk way for > the community to take the new pass for a test drive? >

Hi Gerolf, I think we have several (perhaps separable) issues here: 1. Do we have a canonical form for loops, preserved through the optimizer, that allows naturally-constructed loop nests to remain separable? 2. Do we forbid non-lowering transformations that turn vectorizable loops into non-vectorizable loops? 3. How do we detect cases where transformations cause a negative answer to either

On Wed, Sep 2, 2015 at 5:36 AM, James Molloy <james at jamesmolloy.co.uk> wrote: > Hi, > > Coremark really isn't a good enough test - have you run the LLVM test suite > with this patch, and what were the performance differences? For the test suite single source benches, the 235 tests improved performance, 2 regressed and 705 were unchanged. That seems very optimistic.

On Wed, May 05, 2004 at 03:35:46PM +0200, Anders Alexandersson wrote: > %tmpFunction = load int ()** %puts_kernelPTR > ... > %tmpFunction = load int ()** %puts_kernelPTR > > generates > > Redefinition of value named 'tmpFunction' in the 'int () *' type plane! > > Is it not allowed to reuse variables? Is there some way to do it? LLVM uses the Static