New Solution for memory leak in tblgen

[David Blaikie]

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)

On Mon, Nov 10, 2014 at 9:58 PM, wuhui1973 <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/fc339315/attachment.html>