similar to: [LLVMdev] Cute profiling toy for LLVM

Displaying 20 results from an estimated 400 matches similar to: "[LLVMdev] Cute profiling toy for LLVM"

2005 Apr 29
2
[LLVMdev] IntervalPartition bug?
Hi, 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 anywhere. Here's what's going on in IntervalIterator.h:
2004 Mar 31
0
[LLVMdev] A question about induction variables
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( )
2004 Apr 01
1
[LLVMdev] A question about induction variables
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
2005 Feb 22
0
[LLVMdev] Area for improvement
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,
2006 Jul 09
2
[LLVMdev] Critical edges
Dear guys, I am having problem to split edges correctly. Mostly because the new basic blocks are creating infinite loops. Could someone help me fixing the code below? It is creating assembly like this one below. Block LBB1_9 was inserted to break the critical edge between blocks LBB1_3 and LBB1_8. But it changes the semantics of the original program, because, before, LBB1_8 was falling
2005 Feb 22
0
[LLVMdev] Area for improvement
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
2006 Jul 09
0
[LLVMdev] Critical edges
The problem is that you are inserting block 9 in the wrong spot. mf.getLastBlock() returns the block with the greatest number which may have nothing to do with the ordering. Why not use the end iterator (mf.end) to insert? -Tanya On Sat, 8 Jul 2006, Fernando Magno Quintao Pereira wrote: > > Dear guys, > > I am having problem to split edges correctly. Mostly because the new
2006 Jun 15
0
[LLVMdev] problem with loopinfo
On Thu, 15 Jun 2006, Wei Jiang wrote: > hi, > The loopinfo pass failed to recognize the Tripcount of a simple program constructed by me, can you help me to figure out why this happened? Thanks. > The C program and corresponding .ll files are shown below. I used llvm1.7 to develop my own pass, and want to use the loop information. What passes are you running before your pass? trip
2005 Feb 22
2
[LLVMdev] Area for improvement
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:
2006 Jun 15
2
[LLVMdev] problem with loopinfo
hi, The loopinfo pass failed to recognize the Tripcount of a simple program constructed by me, can you help me to figure out why this happened? Thanks. The C program and corresponding .ll files are shown below. I used llvm1.7 to develop my own pass, and want to use the loop information. -Wei Test.c: #include "stdio.h" #define N 40 void func1() { int a[N]; int i,j; for
2003 Dec 22
1
[LLVMdev] How to explain?
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 ()* }
2006 Jun 15
0
[LLVMdev] problem with loopinfo
On Thu, 15 Jun 2006, Wei Jiang wrote: > I did run the indvars pass, but it seemed that it didn't work. Then you'll have to trace through and find out why it's failing... -Chris > ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> > To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, June 15,
2006 Jun 15
2
[LLVMdev] problem with loopinfo
I did run the indvars pass, but it seemed that it didn't work. -Wei ----- Original Message ----- From: "Chris Lattner" <sabre at nondot.org> To: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> Sent: Thursday, June 15, 2006 3:35 PM Subject: Re: [LLVMdev] problem with loopinfo > On Thu, 15 Jun 2006, Wei Jiang wrote: >> hi, >> The
2004 Dec 04
1
[LLVMdev] Question about writing a pass
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
2004 May 05
0
[LLVMdev] Not allowed to reuse variables?
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
2005 Jun 20
0
[LLVMdev] 'make check' failed with: ... PHI node entries do not match predecessors! ...
Hi Henrik, You don't have the latest C/C++ Front End Source code. Please update from CVS to get the fix for the 2005-06-15-ExpandGotoInternalProblem.c test. Note the date of the test (5 days ago). Reid. On Mon, 2005-06-20 at 18:42 +0200, Henrik Bach wrote: > Hi, > > Now, I've build the tools and the cfe. However, 'make check' gave me the > attached results.
2005 Jun 20
2
[LLVMdev] 'make check' failed with: ... PHI node entries do not match predecessors! ...
Hi, Now, I've build the tools and the cfe. However, 'make check' gave me the attached results. Summarized as follows: # of expected passes 1081 # of unexpected failures 26 # of expected failures 32 I configured llvm with following options: '--prefix=/home/hb/llvm/ --enable-targets=host-only'. I used gcc version 3.4.2 to build the tools and cfe. The cfe is version:
2005 Jun 20
1
[LLVMdev] 'make check' failed with: ... PHI node entries donot match predece
Hi Reid, Now, I've removed the file and updated the source tree with this command: cvs -z3 -d :pserver:anon at llvm-cvs.cs.uiuc.edu:/var/cvs/llvm update -PdR llvm However, the file still exits. Henrik. >From: Reid Spencer >Date: Mon, 20 Jun 2005 10:57:54 -0700 > >Hi Henrik, > >You don't have the latest C/C++ Front End Source code. Please update >from CVS to get
2006 Jul 04
2
[LLVMdev] Critical edges
On Tue, 4 Jul 2006, Fernando Magno Quintao Pereira wrote: > However, it does not remove all the critical edges. I am getting a very > weird dataflow graph (even without the Break Critical edges pass). The > dataflow generated by MachineFunction::dump() for the program below is > given here: > http://compilers.cs.ucla.edu/fernando/projects/soc/images/loop_no_crit2.pdf ... > The
2004 May 09
0
[LLVMdev] Testing LLVM on OS X
On Tue, 4 May 2004, Chris Lattner wrote: > On Tue, 4 May 2004, Chris Lattner wrote: > > I suspect that a large reason that LLVM does worst than a native C > > compiler with the CBE+GCC is that LLVM generates very low-level C code, > > and I'm not convinced that GCC is doing a very good job (ie, without > > syntactic loops). > > Yup, this is EXACTLY what is