[PATCH] D119409: [C++20] [Modules] Remain dynamic initializing internal-linkage variables in module interface unit
Chuanqi Xu via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Mon Mar 21 19:33:45 PDT 2022
ChuanqiXu added a comment.
In D119409#3396690 <https://reviews.llvm.org/D119409#3396690>, @dblaikie wrote:
> Not even necessarily then - if you have code like protobufs (large amounts of autogenerated code, much of which you might never call) - or even just libraries where you only use a subset of their features - then you might have more code generated with an inline-function-homing
>From the perspective of code size, it would be larger in inline-function-homing strategies in cases you described. But I guess it wouldn't hurt in compilation speed, is it? For the consideration of code size, I think we could mitigate the problem by thinLTO. (Although we couldn't solve the problem completely since thinLTO couldn't help for *.o, *.a and *.so files.)
> Possibly - there's still the possibility that even without any importing (& just homing into the module object file) that it'll cost more than it benefits due to inline functions that are never called.
Yeah, I met the situation before. In a simple case, that the time spent on the deserialization looks more than the time we saved. By from my experience (my experience is not complete though), this kind of cases is relatively small.
---
@dblaikie given that the talk involves further optimization, which is beyond the scope of current patch. Would you like to accept this one?
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D119409/new/
https://reviews.llvm.org/D119409
More information about the cfe-commits
mailing list