[PATCH] D119409: [C++20] [Modules] Remain dynamic initializing internal-linkage variables in module interface unit

[David Blaikie via Phabricator via cfe-commits]

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