similar to: [LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'"

2013 Apr 23
2
[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'
Hi, I am investigating a performance degradation between llvm-3.1 and llvm-3.2 (Note: current top-of-tree shows a similar degradation) One issue I see is the following: - 'loop invariant code motion' seems to be depending on the result of the 'reassociate expression' pass: In the samples below I observer the following behavior: Both start with the same expression: %add = add
2013 Apr 23
0
[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'
As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that the earlier definition of the sub-expression is permute earlier in the resulting expr. e.g. outer-loop1 x= outer-loop2 y =
2013 Apr 25
0
[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'
On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > It's an interesting problem. > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > Cooper gives a nice intro in one of his lectures: http://www.cs.rice.edu/~keith/512/2012/Lectures/26ReassocII-1up.pdf > I can't tell, quickly, what's going on
2013 Apr 25
1
[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'
On Thu, Apr 25, 2013 at 9:18 AM, Arnold Schwaighofer < aschwaighofer at apple.com> wrote: > > On Apr 25, 2013, at 10:51 AM, Preston Briggs <preston.briggs at gmail.com> wrote: > > > It's an interesting problem. > > The best stuff I've seen published is by Cooper, Eckhart, & Kennedy, in PACT '08. > > Cooper gives a nice intro in one of his
2013 Apr 25
3
[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'
On Apr 23, 2013, at 10:37 AM, Shuxin Yang <shuxin.llvm at gmail.com> wrote: > As far as I can understand of the code, the Reassociate tries to achieve this result by its "ranking" mechanism. > > If it dose not, it is not hard to achieve this result, just restructure the expression in a way such that > the earlier definition of the sub-expression is permute earlier in
2013 Nov 13
2
[LLVMdev] dominator, post-dominator and memory leak
Hi all, I have been writing a pass to heapify some alloca's (it is pessimistization, not optimization). For example, in the following control flow graph, there is a call to malloc inserted in block BB12. In order to avoid memory leak, free's are needed. The free cannot be inserted in BB23 because BB23 is not dominated by BB12. There are two ways to go I can think of here. One way is to
2013 Nov 13
3
[LLVMdev] dominator, post-dominator and memory leak
Hi Henrique, Thanks for the quick reply! On Tue, Nov 12, 2013 at 9:13 PM, Henrique Santos < henrique.nazare.santos at gmail.com> wrote: > PRE normally uses a latest placement algorithm to do something of the sort. > I don't know about GVN/PRE, but older version of PRE might have it. > Just placing the calls to free at the predecessors (dominated by BB12) of > the dominance
2013 Nov 15
2
[LLVMdev] dominator, post-dominator and memory leak
Hi Henrique, I have tried using -mergereturn and inserting a free into the predecessors of dominance frontier of malloc block and it caused double free. It is possible for multiple free's to be inserted on the path from malloc to an exit. For example, in the following CFG: BB10 (malloc) / \ BB11 BB12 ... / \ / \
2013 Nov 13
0
[LLVMdev] dominator, post-dominator and memory leak
> > It seems that placing the calls to free at the predecessors of dominance > frontier is inadequate. It is possible that there are exit blocks that are > dominated by BB12 (calls to malloc). I guess we can also insert calls to > free at these exit blocks too. That crossed my mind a few minutes later. : ) If you're interested, PRE.cpp existed last at r25315. It calculates the
2013 Nov 13
0
[LLVMdev] dominator, post-dominator and memory leak
PRE normally uses a latest placement algorithm to do something of the sort. I don't know about GVN/PRE, but older version of PRE might have it. Just placing the calls to free at the predecessors (dominated by BB12) of the dominance frontier of BB12 seems to work, however. Is there anything wrong with this? H. On Tue, Nov 12, 2013 at 11:30 PM, Bin Tzeng <bintzeng at gmail.com> wrote:
2013 Nov 15
0
[LLVMdev] dominator, post-dominator and memory leak
Try breaking the critical edges (-break-crit-edges). This way, a new block will be created between BB13 and BB11 (call this BB11.break) and BB15 and BB12 (call this BB12.break). The predecessors of the dominance frontier will, thus, be BB11.break, BB12.break, and BB14. When we enter through a block with a call to malloc(), we will end up in one of the blocks in the dominance frontier (kind of).
2013 Nov 13
2
[LLVMdev] dominator, post-dominator and memory leak
Thanks! I will try that and see whether it works. On Wed, Nov 13, 2013 at 5:01 AM, Henrique Santos < henrique.nazare.santos at gmail.com> wrote: > It seems that placing the calls to free at the predecessors of dominance >> frontier is inadequate. It is possible that there are exit blocks that are >> dominated by BB12 (calls to malloc). I guess we can also insert calls to
2013 Nov 13
0
[LLVMdev] dominator, post-dominator and memory leak
Bill, Just in case this is relevant for you: If you're working with C++ code, or otherwise have any functions that might throw exceptions, you might also need to catch those exceptions in order to free the allocated memory. This will involve looking for calls to functions that mayThrow(), changing their calls to invokes, and freeing the memory before resuming the unwinding. -Hal -----
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
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
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
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,
2008 Dec 07
1
[LLVMdev] How to extract loop body into a new function?
False Alarm!! Still don't know how to do it! I am trying to write a transformation pass to extract a loop body into a function. For example: The Loop in question is: for (i2 = 0; i2 < LOOP_SIZE; i2++) { A[B[i2]] = 2 * B[i2]; } The IR for which is: bb13: ; preds = %bb13, %bb %i2.0.reg2mem.0 = phi i32 [ 0, %bb ], [ %indvar.next62, %bb13 ] ; <i32>
2012 Nov 26
2
[LLVMdev] LSR pass
Hi, I would like some help regarding the LSR pass. It seems that it likes to duplicate address calculations as in the case above, which is highly undesirable on my target. I wonder if there is any way to tell LSR to not duplicate the code in cases like this? Or could I perhaps run CSE after LSR again? What is the logic behind this transformation? It seems that a LSR pass should not insert a
2011 Aug 19
1
[LLVMdev] Break operands into multiple instructions
Hi All, I am creating an instrumentation pass using LLVM libraries. I am using clang++ (version 2.9) to compile cpp code into LLVM bit code. When I generate the llvm bit code using clang++ using -O3, I get many instances of instructions that look like the following. br i1 icmp ne (i8* bitcast (i32 (i32)* @pthread_cancel to i8*), i8* null), label %bb23, label %bb25 Here three LLVM instructions