ChuanqiXu9 wrote: > > > Also, can you please compile real-world modules (e.g. libc++) and show > > > how this affects the PCM size? > > > > > > In my simple test, it didn't affect the PCM size. > > That's why I'm specifically asking for a real-world workload. > > > It makes sense in the theory too. Since on the one hand, the number of > > MacroID and PreprocessedEntityID is much less than other IDs. > > That really depends on the code. > > > And also, we didn't use VBR encoding for MacroID and PreprocessedEntityID > > in my memory. So it might not affect the PCM size significantly. > > For both `PP_MODULE_MACRO` and `PP_MACRO_DIRECTIVE_HISTORY` we store the > `ModuleID` into the `Record` and emit it via `EmitRecord()`, which > VBR6-encodes the values. So I do think we're losing lots of space savings > with this patch.
Yeah, I tried clang std module for libc++ and it shows some size inflation and it goes away after I store MacroID into two slots manually for `PP_MODULE_MACRO`. We can do the same optimization for other *ID types. Let's make it in following patches. And when I reading code, I found `PP_MACRO_DIRECTIVE_HISTORY` record is not actually read IIRC. Maybe this can be an optimization point. https://github.com/llvm/llvm-project/pull/166346 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
