[cfe-dev] Remove unused types from ASTContext

[Reid Kleckner via cfe-dev]

On Tue, May 2, 2017 at 5:37 AM, mats petersson via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> The problem is that the compiler doesn't work anywhere like that
> currently, and I'm pretty sure you can't (with less than lots of months of
> effort, if it's at all possible) make it work like that.
>
> Part of the reason for the compiler "not working like that" is that it
> does things in phases: It forms AST of the entire  program, then runs
> semantic analysis on the entire AST, and then runs the CodeGen on the
> entire AST. Oh, and debug info is generated alongside CodeGen, and knowing
> the types in debug symbols is probably useful [although I don't know how
> useful debuggers are in debugging Template Meta Programming code - not
> something I spend much time working on in general].
>

This is mostly correct, but clang semantic analysis and IR generation
actually happen incrementally after every top-level decl. Some things get
deferred to end of TU, so that triggers further analysis and IR gen.

I'm pretty sure we can't do the "delete" steps Mateusz describes because we
can't instantiate a template once and then throw away the instantiated
specialization later. We have to keep it around in case something would
reinstantiate it. The point of instantiation is pretty important in C++, so
I don't think we would want to implement a mode that throws away implicit
instantiations.

Finally, it's not practical to implement such a mode because we use a
BumpPtrAllocator memory management strategy in ASTContext. That means AST
nodes live until end of TU, and there is no infrastructure to free and
re-allocate their memory.

My understanding is that constexpr functions were designed as a more
convenient, readable, and efficient way to implement these kinds of
metaprograms, so I suggest using them instead.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170502/8418340d/attachment.html>