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 >>>> >>>> >>> >> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20131113/10d12203/attachment.html>
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
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>
Maybe Matching Threads
- [LLVMdev] dominator, post-dominator and memory leak
- [LLVMdev] dominator, post-dominator and memory leak
- [LLVMdev] dominator, post-dominator and memory leak
- [LLVMdev] dominator, post-dominator and memory leak
- [LLVMdev] dominator, post-dominator and memory leak