similar to: [LLVMdev] dominator, post-dominator and memory leak

Displaying 20 results from an estimated 800 matches similar to: "[LLVMdev] dominator, post-dominator and memory leak"

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 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 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
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 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
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 -----
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).
2012 Mar 28
6
How to get all possible combinations?
Dear all, suppose I have a vector with elements as: Vec <- c(2,3,4,5,6) Now I want to have all possible combination of length 3 using those elements and without any repetition. Like, I want to have 1 possibility like 2-3-4 but not 3-2-4. Can somebody guide me how to achieve that in R? Thanks for your help.
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 25
2
[LLVMdev] 'loop invariant code motion' and 'Reassociate Expression'
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 in Reassociate; as usual, the documentation resolutely avoids giving any credit for the ideas. Why is that?
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
2010 Apr 20
2
[LLVMdev] How to delete a instruction?
Hi, when I delete some instruction, I got some error prompt message. - %i.0.reg2mem.0 = phi i32 [ 0, %bb5 ], [ %indvar.next, %bb12 ] ; <i32> [#uses=2] - %s.0.reg2mem.0 = phi i32 [ 0, %bb5 ], [ %tmp16, %bb12 ] ; <i32> [#uses=1] - %tmp14 = tail call i32 @foobar(i32 %i.0.reg2mem.0) nounwind ; <i32> [#uses=1] - %tmp16 = add i32 %tmp14, %s.0.reg2mem.0 ; <i32>
2006 Nov 13
0
[LLVMdev] post-dominance frontier
On Thu, 9 Nov 2006, Ryan M. Lefever wrote: Sorry I never responded to this: > In the literature (see below for a reference), when a dominance frontier > is computed, it is computed from a CFG that contains a dummy entry node > and dummy exit node. Further, those dummy nodes are potential members > of the (post-)dominance frontier for a given basic block. In LLVM, I > could not
2006 Nov 10
2
[LLVMdev] post-dominance frontier
In the literature (see below for a reference), when a dominance frontier is computed, it is computed from a CFG that contains a dummy entry node and dummy exit node. Further, those dummy nodes are potential members of the (post-)dominance frontier for a given basic block. In LLVM, I could not figure out a way to determine if the dummy entry node is a member of the post-dominance frontier of
2009 Jan 28
3
[LLVMdev] uses of unwind lead to crashes
I have what appears to be a bug in LLVM... I'm deeply hesitant to label it a bug, given my lack of experience with LLVM, but the behaviour of this fragment strongly suggests a bug. In particular, compiling and running this fragment using a fresh SVN build yields this stderr: uccello:/tmp clements$ lli a.out.bc 0 lli 0x005e72b6 char const* std::find<char const*,
2014 Dec 05
2
[LLVMdev] InlineSpiller.cpp bug?
Hi Quentin, I have rerun the test case on a recent commit, so the numbers have changed. There are also now a few more basic blocks very small basic blocks in the function, and therefore there are some slight differences. I tried to go back to earlier commits, without success for some reason... This is however very similar, except that there becomes two COPYs back to sibling value after the loop.
2014 Dec 09
2
[LLVMdev] InlineSpiller.cpp bug?
Hi Jonas, Thanks for your patience. After spending some time looking at the additional output you gave me, I agree that your fix is the right one. I was worried that this problem may arise because we were spilling not real user, but in fact what I thought was the problem is an optimization we could do :). See my comments inlined for a few nitpicks before you commit. Thanks again, -Quentin On
2007 Jan 29
2
[LLVMdev] A question about GetElementPtr common subexpression elimination/loop invariant code motion
Hello. I have a problem which is quite basic for array optimization, amd I wonder whether I am missing something, but I could not find the LLVM pass that does it. Consider the following code snippet: int test() { int mat[7][7][7]; int i,j,k,sum=0; for(i=0;i<7;i++){ for(j=0;j<7;j++){ for(k=0;k<7;k++){ sum+=mat[i][j][k]^mat[i][j][k^1]; } } } return
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