[llvm-dev] Splitting up Type.h: Good idea, bad idea?

Chris Lattner via llvm-dev llvm-dev at lists.llvm.org
Tue Apr 7 11:35:56 PDT 2020


+cfe-dev.

Splitting this header up makes sense to me.  Types.h was not intended to be the 7000 line monster it is now :-). 

Splitting QualType out to its own header makes a lot of sense to me, but would it make sense to further split it up somehow?  For example, one could split the C-like types, from the C++-like types, from the extensions.  I’m not sure if that would be useful though.

-Chris

> On Apr 7, 2020, at 10:27 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello Clang folks,
> 
> I was using -ftime-trace to see where the compiler spends time parsing clang's own headers, and it pointed me to Type.h. Many AST headers need QualType to be complete, but they do not need the full type class hierarchy. To improve compile time, I have attempted to create a new header, QualType.h, that defines only the QualType wrapper class. I have started to transition popular clang headers (Decl.h, Expr.h, ASTContext.h, etc) to just use QualType.h. I got pretty far with this, and pushed the results to github:
> https://github.com/llvm/llvm-project/compare/master...rnk:split-qual-type-prune <https://github.com/llvm/llvm-project/compare/master...rnk:split-qual-type-prune>
> 
> You can see it is pretty involved / invasive. Many inline methods had to be sunk to cpp files, and this may affect performance. So far, I have nothing to show for it in build time gains, because there are still too many Type.h includes.
> 
> At this point I am wondering if this is worth doing at all. I figured I would take a break and ask for some opinions. If people generally feel this is worth pursuing, I'll break that branch up and upload it to phab in incremental pieces.
> 
> The next most popular header seems to be CanonicalType.h, and it appears to be pretty strongly coupled to Type.h. It essentially reiterates all of the derived classes of Type, so I'm not sure how to break this link yet.
> 
> Reid
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200407/8da4c0e8/attachment.html>


More information about the llvm-dev mailing list