dblaikie added a comment. In D119409#3398483 <https://reviews.llvm.org/D119409#3398483>, @ChuanqiXu wrote:
> 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? Depending on optimizations, some amount of compilation time is proportional to code size. > 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.) Yep. But with ThinLTO we wouldn't need to produce `available_externally` definitions anyway, since ThinLTO can cross-object import anyway. >> 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? I don't have enough context for the current state of this patch - might be useful to post a summary of the current state? ================ Comment at: clang/test/CodeGenCXX/static-variable-in-module.cpp:2-8 +// RUN: mkdir %t +// RUN: echo "struct S { S(); };" >> %t/foo.h +// RUN: echo "static S s = S();" >> %t/foo.h +// RUN: %clang -std=c++20 -I%t %s -S -emit-llvm -o - | FileCheck %s +module; +#include "foo.h" +export module m; ---------------- urnathan wrote: > ChuanqiXu wrote: > > ChuanqiXu wrote: > > > urnathan wrote: > > > > rather than generate a foo.h file, why not (ab)use the preprocessor > > > > with internal line directives? > > > > > > > > ``` > > > > module; > > > > # 3 __FILE__ 1 // use the next physical line number here (and below) > > > > struct S { S(); }; > > > > static S s = S(); > > > > # 6 "" 2 > > > > export module m; > > > > ... > > > > ``` > > > Yeah, the form is useful when we need to add expected-* diagnostic > > > message to GMF. But I feel it is a little bit hacker. I guess the form > > > mimics looks like user more wouldn't be worse personally. > > Ok, I admit this is really helpful and time saving : ) (Now all my new test > > cases would be wrote in this form) > The other thing you can do, which I've seen elsewhere, is an Input > subdirectory and put the #include file there. I prefer the direct encoding, > 'cos that's less indirection when trying to understand the testcase :) Yeah, I'd be in favor of inline file directives rather than catting source code into other files - that source code may get unwieldy if it needs to be more complicated than a small struct declaration (already catting 3 lines is a bit awkward) and doesn't get syntax highlighting, etc. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D119409/new/ https://reviews.llvm.org/D119409 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
