[clang] [C++20] [Modules] Introduce reduced BMI (PR #75894)
Chuanqi Xu via cfe-commits
cfe-commits at lists.llvm.org
Tue Mar 5 01:55:55 PST 2024
ChuanqiXu9 wrote:
> * I do not want to block progress, so let's move forward with this patch for now.
Yeah. Great to see we have some progress finally. I think this is really important since I see more and more peope complaninig the performance for modules. I feel this series patch is key to to improve the user's impression that named modules are just purely wrappers for PCH.
> * It seems to me (as we found with GMF decl elision) that the process is quite a bit more complex than simply omitting a decl. We need to elide other decls that are then unused (e.g. decls local to an elided function body) and also avoid emitting types that are now no longer existent.
After looking into the codes more, I changed my mind for this. I feel it is the most efficient and the most natural way to omit declarations in ASTWriter.
The idea is, previously, we'll start to write declarations in the current TU from the first declarations. And in the C++20 named modules world, we would start to write declarations from the first declarations in the global module fragment. And we can implement GMF decl elision naturally by writing declarations from the first declaration in the module purview and only write the referenced decl from the GMF during the writing process. This is super natural and efficient.
>
> The process seems to me to be either one of:
>
> * rewriting the AST (which is why my patch set picked the use of the plugin API since that is the purpose there).
> * walking the AST and marking entities as used / not used / elided.
Now I doubt both of the method to be not efficiency and it adds additional burdens to the developers and the users.
>
> It still feels to me to be better to have clear separation of this work from the work of streaming - but if we can make clear layers within the streaming, then maybe the maintenance will not be too hard.
I think the maintainance may not be too hard in that way. ASTWriter is not such a devil :) Probably we need some refactoration in the serialization to make codes more clear. But the point is that we must get the ASTWriter/ASTReader involved. It may not be a good idea to leave the ASTWriter/ASTReader as is and add another layer...
For example, it should be better to not deserialize the declaration from the very beginning instead of deserializing the declaration and judge that it is not wanted/visible. And to achieve this, we must touch the serialization layer deeply.
https://github.com/llvm/llvm-project/pull/75894
More information about the cfe-commits
mailing list