similar to: [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

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:

> > 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

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

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 ... / \ / \

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 -----

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).

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.

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

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?

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 =

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

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>

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

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

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*,

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.

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

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

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