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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to