New Solution for memory leak in tblgen

[Andrew Trick]

> On Nov 10, 2014, at 10:20 PM, David Blaikie <dblaikie at gmail.com> wrote:
> 
> Could you describe the high level design here?
> 
> It looks like there's a static pool (CodeGenDAGPatterns.cpp::memReclaimer) of instances that's used as some kind of last-chance cleanup? Instances of TreePatternNode mostly manage their own lifetime but then if any haven't been destroyed by the time the CodeGenDAGPatterns dtor runs, the remaining elements are destroyed. This is to handle cycles, I take it?
> 
> It still seems like a bit of a GC-esque workaround to handle this case when there might be something better... but I don't know much about tablegen, perhaps there isn't.
> 
> How often are nodes destroyed by themselves? Should we just give up owning these anywhere else & move all ownership into CodeGenDAGPatterns and clean them up in CodeGenDAGPatterns' dtor? (just have a vector of unique_ptrs (maybe even a list or deque of nodes directly owned, rather than via unique_ptr), only create nodes, never destroy them, then destroy them all at the end)

Thanks Hui Wu for simplifying this!

David’s question makes sense to me and I’d be interested to know the answer. Does the proposal to give up ownership make sense to you; would it not significantly simplify the code even further?

-Andy

> On Mon, Nov 10, 2014 at 9:58 PM, wuhui1973 <wuhui1973 at 163.com <mailto:wuhui1973 at 163.com>> wrote:
> Hi Andrew, David and Hal:
> 
> I have made a new solution for this memory leak issue, which is much simpler than previous one. 
> 
> I have tested it, it works well!
> 
> Please have a look, and appreciate any comment.
> 
> Thanks & Regards
> 
> Hui Wu
> 
> 
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141110/d4068b3d/attachment.html>