[LLVMdev] dominator, post-dominator and memory leak

[Bin Tzeng]

Hi Hal,

Thanks for the reminder! You are right that I need to free the allocated
memory when an exception is thrown. Where should the frees be inserted if
an exception is thrown? I am not familiar with the exception handling
mechanism in LLVM.

Bill


On Wed, Nov 13, 2013 at 3:59 PM, Hal Finkel <hfinkel at anl.gov> wrote:

> 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
>
> ----- Original Message -----
> >
> >
> > 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 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 "availability frontier" which is probably what you're looking
> > for.
> >
> > I suggest, however, that you try coming up with another solution
> > instead. You might consider using -mergereturn.
> >
> >
> >
> >
> >
> > H.
> >
> >
> >
> >
> >
> > On Wed, Nov 13, 2013 at 2:13 AM, Bin Tzeng < bintzeng at gmail.com >
> > wrote:
> >
> >
> >
> >
> > 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 frontier of BB12 seems to work, however. Is
> > there anything wrong with this?
> >
> > 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.
> >
> >
> >
> >
> > H.
> >
> >
> >
> >
> >
> >
> > On Tue, Nov 12, 2013 at 11:30 PM, Bin Tzeng < bintzeng at gmail.com >
> > wrote:
> >
> >
> >
> >
> >
> > 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 insert a
> > new basic block, say BB24, to connect both BB21 and BB22 and a free
> > can be inserted into the new block BB24. The new block BB24 has to
> > post-dominate BB12 and all the users of malloc have to happen before
> > BB24. Another way to go is to insert a free in both BB21 and BB22.
> > That is, a free is inserted in all the paths from BB12 to all exits
> > after all users of malloc to avoid memory leak. I wonder whether
> > there is any pass that does similar analysis in order to avoid
> > duplication of efforts.
> >
> >
> > BB10 (entry)
> > / \
> > BB11 BB12 (malloc)
> > / / \
> > BB13 / BB15
> > \ / / \
> > \ / BB18 BB19
> > \ / \ /
> > BB20 BB21 BB22
> > \ | /
> > \ | /
> > \ | /
> > \ | /
> > BB23 (exit)
> >
> >
> > Any advice is appreciated. Thanks in advance!
> > Bill
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
> >
> >
> >
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
>
> --
> Hal Finkel
> Assistant Computational Scientist
> Leadership Computing Facility
> Argonne National Laboratory
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131114/e1661572/attachment.html>