[C++20][Modules] Build module static initializers per P1874R1.

[iains]

Summary

Currently we only implement this for the Itanium ABI since the correct
mangling for the initializers in other ABIs is not yet known.

Intended result:

For a module interface [which includes partition interface and implementation
units] (instead of the generic CXX initializer) we emit a module init that:

• wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit.
• calls module initializers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers.
• We then call initializers for the Global Module Fragment (if present)
• We then call initializers for the current module.
• We then call initializers for the Private Module Fragment (if present)

For a module implementation unit, or a non-module TU that imports at least one
module we emit a regular CXX init that:

• Calls the initializers for any imported modules first.
• Then proceeds as normal with remaining inits.

For all module unit kinds we include a global constructor entry, this allows
for the (in most cases unusual) possibility that a module object could be
included in a final binary without a specific call to its initializer.

Implementation:

• We provide the module pointer in the AST Context so that CodeGen can act on it and its sub-modules.
• We need to account for module build lines like this: clang -cc1 -std=c++20 Foo.pcm -emit-obj -o Foo.o or clang -cc1 -std=c++20 -xc++-module Foo.cpp -emit-obj -o Foo.o
• in order to do this, we add to ParseAST to set the module pointer in the ASTContext, once we establish that this is a module build and we know the module pointer. To be able to do this, we make the query for current module public in Sema.
• In CodeGen, we determine if the current build requires a CXX20-style module init and, if so, we defer any module initializers during the "Eagerly Emitted" phase.
• We then walk the module initializers at the end of the TU but before emitting deferred inits (which adds any hidden and static ones, fixing https://github.com/llvm/llvm-project/issues/51873 ).
• We then proceed to emit the deferred inits and continue to emit the CXX init function.

[iains]

just updated description

[urnathan]

clang/lib/CodeGen/CGDeclCXX.cpp

626–627

'at this time' is ambiguous. I think it means 'the current compiler implementation state', but it could also mean 'at this point in the compilation'. I don't think there's a general problem with such an optimization -- we could emit a flag into the BMI. It's just we don't have the smarts to do that just yet. right?

629

I'm with Morse about this, even before coming to live where I do. You've used both 'ise' and 'ize'. s/ise/ize/

[ChuanqiXu]

clang/include/clang/AST/ASTContext.h

476

The name PrimaryModule looks confusing. PrimaryModule looks like primary module interface unit to me. I think it refers to current module unit only. I think it is better to rename to CurrentModuleUnit.

Then why is it mutable? I don't find it is changed in a const member function.

1085

clang/lib/CodeGen/CGDeclCXX.cpp

621

Recommend to comment related part in your summary. It should be much helpful for other to read the codes.

645–646

mangleModuleInitializer is virtual function and we don't need to cast it.

671

I find the process here for PrioritizedCXXGlobalInits is much simpler than the one done in CodeGenModule::EmitCXXGlobalInitFunc(). It would generate more global init function. Doesn't it matter?

684

Given CodeGenModule is designed as ABI independent, I feel better to avoid see Itanium ABI in this function. (Although we don't have other ABI for modules now..)

692–693

699

Should the Guard be internal linkage? I image that it is possible to be manipulated by different TUs. So I feel like it might be better to be linkonce or linkonce_odr?

706–722

The codes look highly similar to CodeGenModule::EmitCXXGlobalInitFunc. I feel it is better to hoist a new function to avoid repeating the same logic twice.

856

This looks odd since it might be possible to not handling modules. But I understand it might be time-consuming if we want to use CXXGloablInits and we want ModuleInits to be front.

clang/lib/CodeGen/CodeGenModule.cpp

2490

Nit: I feel better to add methods like Module *Module::getGlobalModuleFragment(). I feel odd to use magic string here. But I am OK with it since there many magic string in CodeGen codes and we got in consensus before that we would need to do a lot of refactor work in the future.

2504

Nit: with above: Module *Module::getPrivateModuleFragment().

2934–2936

3208–3209

Is this change needed? Could you elaborate more on this?

clang/lib/CodeGen/CodeGenModule.h

1537

Let's keep consistent with the following. Given CodeGen part uses LLVM IR tensely, clang::Module looks better than Module*

clang/test/CodeGen/module-intializer.cpp

57

I think it is necessary to check the load for the guard and the check.

173

It looks like we lack a test for PrivateModuleFragment.

[ChuanqiXu]

clang/lib/CodeGen/CGDeclCXX.cpp

699

Oh, I realized I'm wrong. Don't remind this one.

[iains]

address review comments

[iains]

not sure why the Debian clang-format is complaining - I am using llvm-14's clang-format with git clang-format + arc.

clang/include/clang/AST/ASTContext.h

476

The name PrimaryModule looks confusing. PrimaryModule looks like primary module interface unit to me. I think it refers to current module unit only. I think it is better to rename to CurrentModuleUnit.

I think we want to be clear that this is the Top Level Module (and not some dependent or sub-module) - so I have renamed to "TopLevelModule".

Then why is it mutable? I don't find it is changed in a const member function.

Ah well caught; the implementation went through several iterations and I missed to remove this.

clang/lib/CodeGen/CGDeclCXX.cpp

621

Hmm. I am not sure exactly what you mean here - there is a comment about the purpose of the method, where the method is declared.
The commit message describes what this method does in the first part. I'm happy to make things more clear, but not sure where you want to see some change,

626–627

yeah, I meant "as currently implemented" - adding flags to the BMI attracts concomitant churn in the serialisation, so probably better done separately. Amended the comment.

629

tools tools ... my editor wants "ise" unless I remember to set it to USian .. and sometimes I miss a change,, hopefully will catch them all as I go.

645–646

Actually, 'mangleModuleInitializer' is not a virtual function of the 'MangleContext' class, only of the 'ItaniumMangleContext'.
(see D122741).

This because we do not know the mangling for MS and, in principle, there might never be such a mangling (e.g. that implementation might deal with P1874 in some different way).

I did have a version of this where I amended the mangling to make the function virtual in the 'MangleContext' class, but then that means generating a dummy MS version that, as noted above, might never exist in reality.

671

In the general CXX initializer the prioritized inits are grouped into functions named in a way that allows them to be collated by other tools (e.g. the static linker) so that init priority can be honoured over multiple TUs.

This is not feasible for module initializers, there is no way to fuze them across TUs (it would have no meaning). So I think all we need to do here is to emit the calls in the correct order (in the end there are no more initializer functions, we just skip the intermediated grouping functions,

Of course, init priority is not mentioned in the standard, so that really what would matter is that compiler 'vendors' agree on a sensible approach to make sure code behaves in an expected manner for common toolchains.

684

Until we have an answer on MS's approach to this, I think it is better to be clear that this only applies to Itanium ABI uses (but if consensus is to remove this, I can do so).

692–693

we need the cast, see above.

706–722

actually, I had considered trying to factor this a bit, but it looks kind of artificial (will consider a second iteration).

856

Yes - otherwise we end up inserting a bunch of stuff, the code is not too long, and the pre-pending is described at the stage it is done.

clang/lib/CodeGen/CodeGenModule.cpp

2490

yeah, I was intending to do this actually - although it only moves the magic strings to a different place. It might be that we have enough bits in the module type enumerator (already streamed) so that we could use up two values with "GMF" and "PMF" module types. However IMO that should be a separate change.

3208–3209

the test is quite heavy, and is used twice when the assertions are enabled (I do not mind to revert this part if that does not seem worthwhile).

clang/test/CodeGen/module-intializer.cpp

57

can you say why?
the main purpose here is to check that we have the right mangled symbols (and some check that there is useful ordering). In what case would you think code-gen could emit the store and somehow not the other parts?

173

yeah, needs to be a second test since we cannot have PMF in a module with partitions.
added one.

[ChuanqiXu]

clang/lib/CodeGen/CGDeclCXX.cpp

621

I mean the paragraph:

For a module (instead of the generic CXX initializer) we emit a module init
that:

- wraps the contained initializations in a control variable to ensure that the inits only happen once, even if a module is imported many times by imports of the main unit.
- calls module initialisers for imported modules first. Note that the order of module import is not significant, and therefore neither is the order of imported module initializers.
- We then call initializers for the Global Module Fragment (if present)
- We then call initializers for the current module.
- We then call initializers for the Private Module Fragment (if present)

I understand people might feel like this is wordy. But, personally, I prefer readability.

645–646

I was just afraid of people might blame us to bring ABI specific things to CodeGen* things. I found there similar uses in CGVTables.cpp and CGVTT.cpp. So this might be acceptable too.

671

Yeah, the prioritized inits are really odd fashion to me.. I only saw such things in assembly. So my understanding to this one is that:
(1) If we have prioritized inits in modules' code , it is not guaranteed to be initialized first. This is the vendors agreement.
(2) If we link a static library (e.g., libgcc.a), the prioritized inits in that would still be initialized first.

Do I understand right?

clang/lib/CodeGen/CodeGenModule.cpp

2490

We still need to use auto * instead of auto here. I remember this is recommended in clang's coding standards.

2504

Use auto* here.

3208–3209

I prefer to do such changes in a standalone NFC patch.

[iains]

clang/lib/CodeGen/CGDeclCXX.cpp

621

so, to clarify - you would like me to add this description as a comment block on the new initializer method (I am OK with doing this)

[ChuanqiXu]

clang/lib/CodeGen/CGDeclCXX.cpp

621

Yeah, I feel it is helpful.

[iains]

rebased, addressed review comments.

clang/lib/CodeGen/CGDeclCXX.cpp

645–646

yes, let us see - if there are any other opinions - personally, I prefer not to generate a dummy function in the MS code.

671

We should avoid side-tracking this patch with too much discussion of the problems of C++ global initialisers. Behaviour of things like static libraries depends on the toolchain, binary container, platform ....

1. prioritised initializers are not part of the standard
2. they are optional (some toolchains do not handle them at all - e.g. macOS)
3. where they are handled, usually the toolchain makes no guarantees about behaviour between TUs
4. (for a regular ELF-style C++ global init) there is a convention to group initializers for a specific priority into a function with a specific mangled name that allows (optionally) external tools - like the linker -to group / order the inits _between_ TUs.

None of this is relevant to Module initializers, we just have to ensure that imported module inits are run before the current module's.

clang/lib/CodeGen/CodeGenModule.cpp

3208–3209

OK .. fair enough, reverted for now.

[ChuanqiXu]

LGTM, thanks!

[iains]

rebased and updated

previously, this was not doing the right thing for module implementation units
which were being processed as if they were interfaces, so we've introduced a module
implemetation type, and that is now checked for in the emitting of the inits.

[iains]

rebased

[iains]

rebased. Amended to include a global CTOR entry for each module kind.

[iains]

@urnathan - I believe that this now implements the same scheme as you have done for GCC (less any of the optimisations).
In particular, we now emit global CTOR entries for module initializers, even though these should really be called explicitly, but as was discussed on the core/sg15 reflectors it is possible (at least for unix-like systems) to construct cases where module objects are included in a final binary without their initializers being called.

[urnathan]

please sed /initialiser/initializer/, I noticed a few had crept in.

[ChuanqiXu]

@iains may I ask what's the issue to not land this? It looks like you're waiting for the behavior to be consistency with GCC?

Since this patch could fix https://github.com/llvm/llvm-project/issues/51873, which breaks the users to compile a hello world example.

[iains]

In D126189#3617850, @ChuanqiXu wrote:

@iains may I ask what's the issue to not land this? It looks like you're waiting for the behavior to be consistency with GCC?

Since this patch could fix https://github.com/llvm/llvm-project/issues/51873, which breaks the users to compile a hello world example.

I need to make some typo corrections; there is no issue (I'm not waiting for anything) just prioritising posting patches to complete C++20 support .. will land this soon.

[iains]

rebased, corrected some spellings.

[iains]

In D126189#3598568, @urnathan wrote:

please sed /initialiser/initializer/, I noticed a few had crept in.

should be done now.

[ChuanqiXu]

In D126189#3617896, @iains wrote:

In D126189#3617850, @ChuanqiXu wrote:

@iains may I ask what's the issue to not land this? It looks like you're waiting for the behavior to be consistency with GCC?

Since this patch could fix https://github.com/llvm/llvm-project/issues/51873, which breaks the users to compile a hello world example.

I need to make some typo corrections; there is no issue (I'm not waiting for anything) just prioritising posting patches to complete C++20 support .. will land this soon.

Thanks! The reason why I am a little bit hurry is that I'm trying to implement std modules: https://github.com/ChuanqiXu9/stdmodules

Now it runs good for libcxx. But it would meet segfault in https://github.com/ChuanqiXu9/stdmodules/blob/master/test/HelloWorld/HelloWorld.cpp for libstdc++ if we don't land this revision.

[JDevlieghere]

This breaks TestDataFormatterLibcxxSpan.py on GreenDragon:

Undefined symbols for architecture x86_64:
  "__ZGIW10std_config", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW4span", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW5array", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW5stdio", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW6string", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW6vector", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45207/

[iains]

In D126189#3642762, @JDevlieghere wrote:

This breaks TestDataFormatterLibcxxSpan.py on GreenDragon:

Undefined symbols for architecture x86_64:
  "__ZGIW10std_config", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW4span", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW5array", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW5stdio", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW6string", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW6vector", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45207/

ack, (I develop on macOS so usually catch these things)...
do you need me to revert the commit - or can we try to find out what's broken and fix it?

[JDevlieghere]

In D126189#3642777, @iains wrote:

In D126189#3642762, @JDevlieghere wrote:

This breaks TestDataFormatterLibcxxSpan.py on GreenDragon:

Undefined symbols for architecture x86_64:
  "__ZGIW10std_config", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW4span", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW5array", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW5stdio", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW6string", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o
  "__ZGIW6vector", referenced from:
      __GLOBAL__sub_I_main.cpp in main.o

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45207/

ack, (I develop on macOS so usually catch these things)...
do you need me to revert the commit - or can we try to find out what's broken and fix it?

If you think you'll be able to get to the bottom of this quickly then I don't think we need to revert, but the bot has been red for a while (which means that other issues can get buried) so I'd like to get it green ASAP.

[iains]

In D126189#3642777, @iains wrote:

In D126189#3642762, @JDevlieghere wrote:

This breaks TestDataFormatterLibcxxSpan.py on GreenDragon:

Undefined symbols for architecture x86_64:

<snip>..

"__ZGIW6vector", referenced from:
    __GLOBAL__sub_I_main.cpp in main.o

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45207/

ack, (I develop on macOS so usually catch these things)...
do you need me to revert the commit - or can we try to find out what's broken and fix it?

hmm there seems to be a compiler error, which looks somewhat unrelated to the active patch:

/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp:125:27: error: no type named 'size_t' in namespace 'std'
  void* operator new(std::size_t, T) {
                     ~~~~~^
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp:132:29: error: no type named 'size_t' in namespace 'std'
  void* operator new[](std::size_t, T) {

[iains]

In D126189#3642779, @JDevlieghere wrote:

In D126189#3642777, @iains wrote:

In D126189#3642762, @JDevlieghere wrote:

This breaks TestDataFormatterLibcxxSpan.py on GreenDragon:

....

https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/45207/

ack, (I develop on macOS so usually catch these things)...
do you need me to revert the commit - or can we try to find out what's broken and fix it?

If you think you'll be able to get to the bottom of this quickly then I don't think we need to revert, but the bot has been red for a while (which means that other issues can get buried) so I'd like to get it green ASAP.

JFTR, I did not get any notification from green dragon (which is odd, AFAIR it's sent email before) or I would have looked right away - kicked off a build will take a look as soon as that's done.

[JDevlieghere]

In D126189#3642820, @iains wrote:

JFTR, I did not get any notification from green dragon (which is odd, AFAIR it's sent email before) or I would have looked right away - kicked off a build will take a look as soon as that's done.

Yes, the bot was already red because of a different issue.

FWIW I tried reverting ac507102d258b6fc0cb57eb60c9dfabd57ff562f and 4328b960176f4394416093e640ad4265bde65ad7 locally and I'm still getting a linker error about missing symbols:

Undefined symbols for architecture arm64:
  "vtable for std::__1::format_error", referenced from:
      std::__1::format_error::format_error(char const*) in main.o
      std::__1::format_error::format_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in main.o

[iains]

In D126189#3642992, @JDevlieghere wrote:

In D126189#3642820, @iains wrote:

JFTR, I did not get any notification from green dragon (which is odd, AFAIR it's sent email before) or I would have looked right away - kicked off a build will take a look as soon as that's done.

Yes, the bot was already red because of a different issue.

FWIW I tried reverting ac507102d258b6fc0cb57eb60c9dfabd57ff562f and 4328b960176f4394416093e640ad4265bde65ad7 locally and I'm still getting a linker error about missing symbols:

those refs come up as 'bad object' for me .. can you identify the upstream changes?

Undefined symbols for architecture arm64:
  "vtable for std::__1::format_error", referenced from:
      std::__1::format_error::format_error(char const*) in main.o
      std::__1::format_error::format_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in main.o

That seems also unrelated to the modules code, but I could always be surprised :)

[JDevlieghere]

In D126189#3643001, @iains wrote:

In D126189#3642992, @JDevlieghere wrote:

In D126189#3642820, @iains wrote:

JFTR, I did not get any notification from green dragon (which is odd, AFAIR it's sent email before) or I would have looked right away - kicked off a build will take a look as soon as that's done.

Yes, the bot was already red because of a different issue.

FWIW I tried reverting ac507102d258b6fc0cb57eb60c9dfabd57ff562f and 4328b960176f4394416093e640ad4265bde65ad7 locally and I'm still getting a linker error about missing symbols:

those refs come up as 'bad object' for me .. can you identify the upstream changes?

That's odd, both Github and Phab think those are the canonical hashes:

https://github.com/llvm/llvm-project/commit/ac507102d258b6fc0cb57eb60c9dfabd57ff562f
https://github.com/llvm/llvm-project/commit/4328b960176f4394416093e640ad4265bde65ad7

Undefined symbols for architecture arm64:
  "vtable for std::__1::format_error", referenced from:
      std::__1::format_error::format_error(char const*) in main.o
      std::__1::format_error::format_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in main.o

That seems also unrelated to the modules code, but I could always be surprised :)

[iains]

In D126189#3643021, @JDevlieghere wrote:

In D126189#3643001, @iains wrote:

In D126189#3642992, @JDevlieghere wrote:

In D126189#3642820, @iains wrote:

JFTR, I did not get any notification from green dragon (which is odd, AFAIR it's sent email before) or I would have looked right away - kicked off a build will take a look as soon as that's done.

Yes, the bot was already red because of a different issue.

FWIW I tried reverting ac507102d258b6fc0cb57eb60c9dfabd57ff562f and 4328b960176f4394416093e640ad4265bde65ad7 locally and I'm still getting a linker error about missing symbols:

those refs come up as 'bad object' for me .. can you identify the upstream changes?

That's odd, both Github and Phab think those are the canonical hashes:

https://github.com/llvm/llvm-project/commit/ac507102d258b6fc0cb57eb60c9dfabd57ff562f
https://github.com/llvm/llvm-project/commit/4328b960176f4394416093e640ad4265bde65ad7

pilot error (pasto...)

Undefined symbols for architecture arm64:
  "vtable for std::__1::format_error", referenced from:
      std::__1::format_error::format_error(char const*) in main.o
      std::__1::format_error::format_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in main.o

That seems also unrelated to the modules code, but I could always be surprised :)

OK - so if I cannot figure out what is happening in the next couple or hours, I can revert those two commits (that's 9PM for me so I probably cannot do much more today).

[JDevlieghere]

In D126189#3643045, @iains wrote:

In D126189#3643021, @JDevlieghere wrote:

In D126189#3643001, @iains wrote:

In D126189#3642992, @JDevlieghere wrote:

In D126189#3642820, @iains wrote:

JFTR, I did not get any notification from green dragon (which is odd, AFAIR it's sent email before) or I would have looked right away - kicked off a build will take a look as soon as that's done.

Yes, the bot was already red because of a different issue.

FWIW I tried reverting ac507102d258b6fc0cb57eb60c9dfabd57ff562f and 4328b960176f4394416093e640ad4265bde65ad7 locally and I'm still getting a linker error about missing symbols:

those refs come up as 'bad object' for me .. can you identify the upstream changes?

That's odd, both Github and Phab think those are the canonical hashes:

https://github.com/llvm/llvm-project/commit/ac507102d258b6fc0cb57eb60c9dfabd57ff562f
https://github.com/llvm/llvm-project/commit/4328b960176f4394416093e640ad4265bde65ad7

pilot error (pasto...)

Undefined symbols for architecture arm64:
  "vtable for std::__1::format_error", referenced from:
      std::__1::format_error::format_error(char const*) in main.o
      std::__1::format_error::format_error(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in main.o

That seems also unrelated to the modules code, but I could always be surprised :)

OK - so if I cannot figure out what is happening in the next couple or hours, I can revert those two commits (that's 9PM for me so I probably cannot do much more today).

Thanks, if the bot reproduces the other issue I mentioned I'll bisect it down to see if there's another commit that's causing issues. I should've mentioned that that failures only happens when building with -gmodules, so it does sound somewhat related.

[iains]

I need to do some more builds to be able to reproduce this - my guess (at present) is that this is a manifestation of '-fcxx-modules -std=c++20' being almost, but not exactly, the same as C++20 standardised modules. It is possible that the -gmodules flag interacts with that (although one might have expected more than one fail if that were so).

edit: as far as the effort to implement standardised C++20 modules goes, there have been no modifications -gmodules; the intent has been all along to leave clang modules (and c++modules) operating "as before".

[dblaikie]

hmm there seems to be a compiler error, which looks somewhat unrelated to the active patch:

/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp:125:27: error: no type named 'size_t' in namespace 'std'
  void* operator new(std::size_t, T) {
                     ~~~~~^
/Users/buildslave/jenkins/workspace/lldb-cmake/llvm-project/cross-project-tests/debuginfo-tests/clang_llvm_roundtrip/simplified_template_names.cpp:132:29: error: no type named 'size_t' in namespace 'std'
  void* operator new[](std::size_t, T) {

Added the missing include here 4ca205855267191ccfd191539cf4b3ed792a4257

[iains]

reopening to post the patch I intend to land.

[iains]

rebased, fixed the interaction with clang module map modules.

[h-vetinari]

Is it realistic for this to land before LLVM 15 branches? Would be great!

[iains]

In D126189#3662123, @h-vetinari wrote:

Is it realistic for this to land before LLVM 15 branches? Would be great!

that is the intention - I just got side-tracked with trying to replicate the test fails that got the commit reverted. AFAICT it's OK now, and i plan to re-land it soon.

[ChuanqiXu]

I feel like we could land this sooner to avoid any unimagined failures.

clang/include/clang/AST/ASTContext.h

class ASTContext : public RefCountedBase<ASTContext> {
   struct PerModuleInitializers {
     llvm::SmallVector<Decl*, 4> Initializers;
     llvm::SmallVector<uint32_t, 4> LazyInitializers;
 
     void resolve(ASTContext &Ctx);
   };
   llvm::DenseMap<Module*, PerModuleInitializers*> ModuleInitializers;
 
+  /// For module code-gen cases, this is the top-level module we are building.
+  Module *TopLevelModule = nullptr;
+
   static constexpr unsigned ConstantArrayTypesLog2InitSize = 8;
   static constexpr unsigned GeneralTypesLog2InitSize = 9;
   static constexpr unsigned FunctionProtoTypesLog2InitSize = 12;
 
   ASTContext &this_() { return *this; }
 
 public:
   /// A type synonym for the TemplateOrInstantiation mapping.
public:
   /// or an ImportDecl nominating another module that has initializers.
   void addModuleInitializer(Module *M, Decl *Init);
 
   void addLazyModuleInitializers(Module *M, ArrayRef<uint32_t> IDs);
 
   /// Get the initializations to perform when importing a module, if any.
   ArrayRef<Decl*> getModuleInitializers(Module *M);
 
+  /// Set the (C++20) module we are building.
+  void setModuleForCodeGen(Module *M) { TopLevelModule = M; }
+
+  /// Get module under construction, nullptr if this is not a C++20 module.
+  Module *getModuleForCodeGen() const { return TopLevelModule; }
+
   TranslationUnitDecl *getTranslationUnitDecl() const {
     return TUDecl->getMostRecentDecl();
   }
   void addTranslationUnitDecl() {
     assert(!TUDecl || TUKind == TU_Incremental);
     TranslationUnitDecl *NewTUDecl = TranslationUnitDecl::Create(*this);
     if (TraversalScope.empty() || TraversalScope.back() == TUDecl)
       TraversalScope = {NewTUDecl};

clang/include/clang/Basic/Module.h

public:
   void markUnavailable(bool Unimportable);
 
   /// Find the submodule with the given name.
   ///
   /// \returns The submodule if found, or NULL otherwise.
   Module *findSubmodule(StringRef Name) const;
   Module *findOrInferSubmodule(StringRef Name);
 
+  /// Get the Global Module Fragment (sub-module) for this module, it there is
+  /// one.
+  ///
+  /// \returns The GMF sub-module if found, or NULL otherwise.
+  Module *getGlobalModuleFragment() { return findSubmodule("<global>"); }
+
+  /// Get the Private Module Fragment (sub-module) for this module, it there is
+  /// one.
+  ///
+  /// \returns The PMF sub-module if found, or NULL otherwise.
+  Module *getPrivateModuleFragment() { return findSubmodule("<private>"); }
+
   /// Determine whether the specified module would be visible to
   /// a lookup at the end of this module.
   ///
   /// FIXME: This may return incorrect results for (submodules of) the
   /// module currently being built, if it's queried before we see all
   /// of its imports.
   bool isModuleVisible(const Module *M) const {
     if (VisibleModulesCache.empty())

clang/include/clang/Sema/Sema.h

private:
   clang::Module *GlobalModuleFragment = nullptr;
 
   /// The modules we imported directly.
   llvm::SmallPtrSet<clang::Module *, 8> DirectModuleImports;
 
   /// Namespace definitions that we will export when they finish.
   llvm::SmallPtrSet<const NamespaceDecl*, 8> DeferredExportedNamespaces;
 
-  /// Get the module unit whose scope we are currently within.
-  Module *getCurrentModule() const {
-    return ModuleScopes.empty() ? nullptr : ModuleScopes.back().Module;
-  }
-
   /// Helper function to judge if we are in module purview.
   /// Return false if we are not in a module.
   bool isCurrentModulePurview() const {
     return getCurrentModule() ? getCurrentModule()->isModulePurview() : false;
   }
 
   /// Enter the scope of the global module.
   Module *PushGlobalModuleFragment(SourceLocation BeginLoc, bool IsImplicit);
   /// Leave the scope of the global module.
   void PopGlobalModuleFragment();
 
   VisibleModuleSet VisibleModules;
 
   /// Cache for module units which is usable for current module.
   llvm::DenseSet<const Module *> UsableModuleUnitsCache;
 
   bool isUsableModule(const Module *M);
 
 public:
+  /// Get the module whose scope we are currently within.
+  Module *getCurrentModule() const {
+    return ModuleScopes.empty() ? nullptr : ModuleScopes.back().Module;
+  }
+
   /// Get the module owning an entity.
   Module *getOwningModule(const Decl *Entity) {
     return Entity->getOwningModule();
   }
 
   bool isModuleDirectlyImported(const Module *M) {
     return DirectModuleImports.contains(M);
   }

clang/lib/CodeGen/CGDeclCXX.cpp

void CodeGenModule::EmitCXXThreadLocalInitFunc() {
   getCXXABI().EmitThreadLocalInitFuncs(
       *this, CXXThreadLocals, CXXThreadLocalInits, CXXThreadLocalInitVars);
 
   CXXThreadLocalInits.clear();
   CXXThreadLocalInitVars.clear();
   CXXThreadLocals.clear();
 }
 
+/* Build the initializer for a C++20 module:
+   This is arranged to be run only once regardless of how many times the module
+   might be included transitively.  This arranged by using a control variable.
+
+   First we call any initializers for imported modules.
+   We then call initializers for the Global Module Fragment (if present)
+   We then call initializers for the current module.
+   We then call initializers for the Private Module Fragment (if present)
+*/
+
+void CodeGenModule::EmitCXXModuleInitFunc(Module *Primary) {
+  while (!CXXGlobalInits.empty() && !CXXGlobalInits.back())
+    CXXGlobalInits.pop_back();
+
+  // We create the function, even if it is empty, since an importer of this
+  // module will refer to it unconditionally (for the current implementation
+  // there is no way for the importer to know that an importee does not need
+  // an initializer to be run).
+
+  // Module initializers for imported modules are emitted first.
+  // Collect the modules that we import
+  SmallVector<Module *> AllImports;
+  // Ones that we export
+  for (auto I : Primary->Exports)
+    AllImports.push_back(I.getPointer());
+  // Ones that we only import.
+  for (Module *M : Primary->Imports)
+    AllImports.push_back(M);
+
+  SmallVector<llvm::Function *, 8> ModuleInits;
+  for (Module *M : AllImports) {
+    llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
+    SmallString<256> FnName;
+    {
+      llvm::raw_svector_ostream Out(FnName);
+      cast<ItaniumMangleContext>(getCXXABI().getMangleContext())
+          .mangleModuleInitializer(M, Out);
+    }
+    assert(!GetGlobalValue(FnName.str()) &&
+           "We should only have one use of the initializer call");
+    llvm::Function *Fn = llvm::Function::Create(
+        FTy, llvm::Function::ExternalLinkage, FnName.str(), &getModule());
+    ModuleInits.push_back(Fn);
+  }
+  AllImports.clear();
+
+  // Add any initializers with specified priority; this uses the same  approach
+  // as EmitCXXGlobalInitFunc().
+  if (!PrioritizedCXXGlobalInits.empty()) {
+    SmallVector<llvm::Function *, 8> LocalCXXGlobalInits;
+    llvm::array_pod_sort(PrioritizedCXXGlobalInits.begin(),
+                         PrioritizedCXXGlobalInits.end());
+    for (SmallVectorImpl<GlobalInitData>::iterator
+             I = PrioritizedCXXGlobalInits.begin(),
+             E = PrioritizedCXXGlobalInits.end();
+         I != E;) {
+      SmallVectorImpl<GlobalInitData>::iterator PrioE =
+          std::upper_bound(I + 1, E, *I, GlobalInitPriorityCmp());
+
+      for (; I < PrioE; ++I)
+        ModuleInits.push_back(I->second);
+    }
+    PrioritizedCXXGlobalInits.clear();
+  }
+
+  // Now append the ones without specified priority.
+  for (auto F : CXXGlobalInits)
+    ModuleInits.push_back(F);
+  CXXGlobalInits.clear();
+
+  llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
+  const CGFunctionInfo &FI = getTypes().arrangeNullaryFunction();
+
+  // We now build the initializer for this module, which has a mangled name
+  // as per the Itanium ABI .  The action of the initializer is guarded so that
+  // each init is run just once (even though a module might be imported
+  // multiple times via nested use).
+  llvm::Function *Fn;
+  llvm::GlobalVariable *Guard = nullptr;
+  {
+    SmallString<256> InitFnName;
+    llvm::raw_svector_ostream Out(InitFnName);
+    cast<ItaniumMangleContext>(getCXXABI().getMangleContext())
+        .mangleModuleInitializer(getContext().getModuleForCodeGen(), Out);
+    Fn = CreateGlobalInitOrCleanUpFunction(
+        FTy, llvm::Twine(InitFnName), FI, SourceLocation(), false,
+        llvm::GlobalVariable::ExternalLinkage);
+
+    Guard = new llvm::GlobalVariable(getModule(), Int8Ty, /*isConstant=*/false,
+                                     llvm::GlobalVariable::InternalLinkage,
+                                     llvm::ConstantInt::get(Int8Ty, 0),
+                                     InitFnName.str() + "__in_chrg");
+  }
+  CharUnits GuardAlign = CharUnits::One();
+  Guard->setAlignment(GuardAlign.getAsAlign());
+
+  CodeGenFunction(*this).GenerateCXXGlobalInitFunc(
+      Fn, ModuleInits, ConstantAddress(Guard, Int8Ty, GuardAlign));
+
+  // See the comment in EmitCXXGlobalInitFunc about OpenCL global init
+  // functions.
+  if (getLangOpts().OpenCL) {
+    GenOpenCLArgMetadata(Fn);
+    Fn->setCallingConv(llvm::CallingConv::SPIR_KERNEL);
+  }
+
+  assert(!getLangOpts().CUDA || !getLangOpts().CUDAIsDevice ||
+         getLangOpts().GPUAllowDeviceInit);
+  if (getLangOpts().HIP && getLangOpts().CUDAIsDevice) {
+    Fn->setCallingConv(llvm::CallingConv::AMDGPU_KERNEL);
+    Fn->addFnAttr("device-init");
+  }
+
+  ModuleInits.clear();
+}
+
 static SmallString<128> getTransformedFileName(llvm::Module &M) {
   SmallString<128> FileName = llvm::sys::path::filename(M.getName());
 
   if (FileName.empty())
     FileName = "<null>";
 
   for (size_t i = 0; i < FileName.size(); ++i) {
     // Replace everything that's not [a-zA-Z0-9._] with a _. This set happens
static std::string getPrioritySuffix(unsigned int Priority) {
   return PrioritySuffix;
 }
 
 void
 CodeGenModule::EmitCXXGlobalInitFunc() {
   while (!CXXGlobalInits.empty() && !CXXGlobalInits.back())
     CXXGlobalInits.pop_back();
 
-  if (CXXGlobalInits.empty() && PrioritizedCXXGlobalInits.empty())
+  // When we import C++20 modules, we must run their initializers first.
+  SmallVector<llvm::Function *, 8> ModuleInits;
+  if (CXX20ModuleInits)
+    for (Module *M : ImportedModules) {
+      llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
+      SmallString<256> FnName;
+      {
+        llvm::raw_svector_ostream Out(FnName);
+        cast<ItaniumMangleContext>(getCXXABI().getMangleContext())
+            .mangleModuleInitializer(M, Out);
+      }
+      assert(!GetGlobalValue(FnName.str()) &&
+             "We should only have one use of the initializer call");
+      llvm::Function *Fn = llvm::Function::Create(
+          FTy, llvm::Function::ExternalLinkage, FnName.str(), &getModule());
+      ModuleInits.push_back(Fn);
+    }
+
+  if (ModuleInits.empty() && CXXGlobalInits.empty() &&
+      PrioritizedCXXGlobalInits.empty())
     return;
 
   llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);
   const CGFunctionInfo &FI = getTypes().arrangeNullaryFunction();
 
   // Create our global prioritized initialization function.
   if (!PrioritizedCXXGlobalInits.empty()) {
     SmallVector<llvm::Function *, 8> LocalCXXGlobalInits;
for (SmallVectorImpl<GlobalInitData >::iterator
         PrioE = std::upper_bound(I + 1, E, *I, GlobalInitPriorityCmp());
 
       LocalCXXGlobalInits.clear();
 
       unsigned int Priority = I->first.priority;
       llvm::Function *Fn = CreateGlobalInitOrCleanUpFunction(
           FTy, "_GLOBAL__I_" + getPrioritySuffix(Priority), FI);
 
+      // Prepend the module inits to the highest priority set.
+      if (!ModuleInits.empty()) {
+        for (auto F : ModuleInits)
+          LocalCXXGlobalInits.push_back(F);
+        ModuleInits.clear();
+      }
+
       for (; I < PrioE; ++I)
         LocalCXXGlobalInits.push_back(I->second);
 
       CodeGenFunction(*this).GenerateCXXGlobalInitFunc(Fn, LocalCXXGlobalInits);
       AddGlobalCtor(Fn, Priority);
     }
     PrioritizedCXXGlobalInits.clear();
   }
 
-  if (getCXXABI().useSinitAndSterm() && CXXGlobalInits.empty())
+  if (getCXXABI().useSinitAndSterm() && ModuleInits.empty() &&
+      CXXGlobalInits.empty())
     return;
 
+  for (auto F : CXXGlobalInits)
+    ModuleInits.push_back(F);
+  CXXGlobalInits.clear();
+
   // Include the filename in the symbol name. Including "sub_" matches gcc
   // and makes sure these symbols appear lexicographically behind the symbols
   // with priority emitted above.
-  llvm::Function *Fn = CreateGlobalInitOrCleanUpFunction(
-      FTy, llvm::Twine("_GLOBAL__sub_I_", getTransformedFileName(getModule())),
+  llvm::Function *Fn;
+  if (CXX20ModuleInits && getContext().getModuleForCodeGen()) {
+    SmallString<256> InitFnName;
+    llvm::raw_svector_ostream Out(InitFnName);
+    cast<ItaniumMangleContext>(getCXXABI().getMangleContext())
+        .mangleModuleInitializer(getContext().getModuleForCodeGen(), Out);
+    Fn = CreateGlobalInitOrCleanUpFunction(
+        FTy, llvm::Twine(InitFnName), FI, SourceLocation(), false,
+        llvm::GlobalVariable::ExternalLinkage);
+  } else
+    Fn = CreateGlobalInitOrCleanUpFunction(
+        FTy,
+        llvm::Twine("_GLOBAL__sub_I_", getTransformedFileName(getModule())),
         FI);
 
-  CodeGenFunction(*this).GenerateCXXGlobalInitFunc(Fn, CXXGlobalInits);
+  CodeGenFunction(*this).GenerateCXXGlobalInitFunc(Fn, ModuleInits);
   AddGlobalCtor(Fn);
 
   // In OpenCL global init functions must be converted to kernels in order to
   // be able to launch them from the host.
   // FIXME: Some more work might be needed to handle destructors correctly.
   // Current initialization function makes use of function pointers callbacks.
   // We can't support function pointers especially between host and device.
   // However it seems global destruction has little meaning without any
   // dynamic resource allocation on the device and program scope variables are
   // destroyed by the runtime when program is released.
   if (getLangOpts().OpenCL) {
     GenOpenCLArgMetadata(Fn);
     Fn->setCallingConv(llvm::CallingConv::SPIR_KERNEL);
   }
 
   assert(!getLangOpts().CUDA || !getLangOpts().CUDAIsDevice ||
          getLangOpts().GPUAllowDeviceInit);
   if (getLangOpts().HIP && getLangOpts().CUDAIsDevice) {
     Fn->setCallingConv(llvm::CallingConv::AMDGPU_KERNEL);
     Fn->addFnAttr("device-init");
   }
 
-  CXXGlobalInits.clear();
+  ModuleInits.clear();
 }
 
 void CodeGenModule::EmitCXXGlobalCleanUpFunc() {
   if (CXXGlobalDtorsOrStermFinalizers.empty() &&
       PrioritizedCXXStermFinalizers.empty())
     return;
 
   llvm::FunctionType *FTy = llvm::FunctionType::get(VoidTy, false);

clang/lib/CodeGen/CodeGenModule.h

private:
   const CodeGenOptions &CodeGenOpts;
   unsigned NumAutoVarInit = 0;
   llvm::Module &TheModule;
   DiagnosticsEngine &Diags;
   const TargetInfo &Target;
   std::unique_ptr<CGCXXABI> ABI;
   llvm::LLVMContext &VMContext;
   std::string ModuleNameHash;
-
+  bool CXX20ModuleInits = false;
   std::unique_ptr<CodeGenTBAA> TBAA;
 
   mutable std::unique_ptr<TargetCodeGenInfo> TheTargetCodeGenInfo;
 
   // This should not be moved earlier, since its initialization depends on some
   // of the previous reference members being already initialized and also checks
   // if TheTargetCodeGenInfo is NULL
   CodeGenTypes Types;
private:
   // C++ related functions.
 
   void EmitDeclContext(const DeclContext *DC);
   void EmitLinkageSpec(const LinkageSpecDecl *D);
 
   /// Emit the function that initializes C++ thread_local variables.
   void EmitCXXThreadLocalInitFunc();
 
+  /// Emit the function that initializes global variables for a C++ Module.
+  void EmitCXXModuleInitFunc(clang::Module *Primary);
+
   /// Emit the function that initializes C++ globals.
   void EmitCXXGlobalInitFunc();
 
   /// Emit the function that performs cleanup associated with C++ globals.
   void EmitCXXGlobalCleanUpFunc();
 
   /// Emit the function that initializes the specified global (if PerformInit is
   /// true) and registers its destructor.
private:
 
   /// Emit a dummy function that reference a CoreFoundation symbol when
   /// @available is used on Darwin.
   void emitAtAvailableLinkGuard();
 
   /// Emit the llvm.used and llvm.compiler.used metadata.
   void emitLLVMUsed();
 
+  /// For C++20 Itanium ABI, emit the initializers for the module.
+  void EmitModuleInitializers(clang::Module *Primary);
+
   /// Emit the link options introduced by imported modules.
   void EmitModuleLinkOptions();
 
   /// Helper function for EmitStaticExternCAliases() to redirect ifuncs that
   /// have a resolver name that matches 'Elem' to instead resolve to the name of
   /// 'CppFunc'. This redirection is necessary in cases where 'Elem' has a name
   /// that will be emitted as an alias of the name bound to 'CppFunc'; ifuncs
   /// may not reference aliases. Redirection is only performed if 'Elem' is only

clang/lib/CodeGen/CodeGenModule.cpp

IntPtrTy = llvm::IntegerType::get(LLVMContext,
     C.getTargetInfo().getMaxPointerWidth());
   Int8PtrTy = Int8Ty->getPointerTo(0);
   Int8PtrPtrTy = Int8PtrTy->getPointerTo(0);
   const llvm::DataLayout &DL = M.getDataLayout();
   AllocaInt8PtrTy = Int8Ty->getPointerTo(DL.getAllocaAddrSpace());
   GlobalsInt8PtrTy = Int8Ty->getPointerTo(DL.getDefaultGlobalsAddressSpace());
   ASTAllocaAddressSpace = getTargetCodeGenInfo().getASTAllocaAddressSpace();
 
+  // Build C++20 Module initializers.
+  // TODO: Add Microsoft here once we know the mangling required for the
+  // initializers.
+  CXX20ModuleInits =
+      LangOpts.CPlusPlusModules && getCXXABI().getMangleContext().getKind() ==
+                                       ItaniumMangleContext::MK_Itanium;
+
   RuntimeCC = getTargetCodeGenInfo().getABIInfo().getRuntimeCC();
 
   if (LangOpts.ObjC)
     createObjCRuntime();
   if (LangOpts.OpenCL)
     createOpenCLRuntime();
   if (LangOpts.OpenMP)
     createOpenMPRuntime();
if (GV.isDeclarationForLinker()) {
                            : NoDLLStorageClassVisibility);
     }
 
     GV.setDLLStorageClass(llvm::GlobalValue::DefaultStorageClass);
   }
 }
 
 void CodeGenModule::Release() {
+  Module *Primary = getContext().getModuleForCodeGen();
+  if (CXX20ModuleInits && Primary)
+    EmitModuleInitializers(Primary);
   EmitDeferred();
   EmitVTablesOpportunistically();
   applyGlobalValReplacements();
   applyReplacements();
   emitMultiVersionFunctions();
+  if (CXX20ModuleInits && Primary)
+    EmitCXXModuleInitFunc(Primary);
+  else
     EmitCXXGlobalInitFunc();
   EmitCXXGlobalCleanUpFunc();
   registerGlobalDtorsWithAtExit();
   EmitCXXThreadLocalInitFunc();
   if (ObjCRuntime)
     if (llvm::Function *ObjCInitFunction = ObjCRuntime->ModuleInitFunction())
       AddGlobalCtor(ObjCInitFunction);
   if (Context.getLangOpts().CUDA && CUDARuntime) {
     if (llvm::Function *CudaCtorFunction = CUDARuntime->finalizeModule())
if (IsELF) {
       llvm::SmallString<24> Opt;
       CGM.getTargetCodeGenInfo().getDependentLibraryOption(LL.Library, Opt);
       auto *OptString = llvm::MDString::get(Context, Opt);
       Metadata.push_back(llvm::MDNode::get(Context, OptString));
     }
   }
 }
 
+void CodeGenModule::EmitModuleInitializers(clang::Module *Primary) {
+  // Emit the initializers in the order that sub-modules appear in the
+  // source, first Global Module Fragments, if present.
+  if (auto GMF = Primary->getGlobalModuleFragment()) {
+    for (Decl *D : getContext().getModuleInitializers(GMF)) {
+      assert(D->getKind() == Decl::Var && "GMF initializer decl is not a var?");
+      EmitTopLevelDecl(D);
+    }
+  }
+  // Second any associated with the module, itself.
+  for (Decl *D : getContext().getModuleInitializers(Primary)) {
+    // Skip import decls, the inits for those are called explicitly.
+    if (D->getKind() == Decl::Import)
+      continue;
+    EmitTopLevelDecl(D);
+  }
+  // Third any associated with the Privat eMOdule Fragment, if present.
+  if (auto PMF = Primary->getPrivateModuleFragment()) {
+    for (Decl *D : getContext().getModuleInitializers(PMF)) {
+      assert(D->getKind() == Decl::Var && "PMF initializer decl is not a var?");
+      EmitTopLevelDecl(D);
+    }
+  }
+}
+
 void CodeGenModule::EmitModuleLinkOptions() {
   // Collect the set of all of the modules we want to visit to emit link
   // options, which is essentially the imported modules and all of their
   // non-explicit child modules.
   llvm::SetVector<clang::Module *> LinkModules;
   llvm::SmallPtrSet<clang::Module *, 16> Visited;
   SmallVector<clang::Module *, 16> Stack;
 
bool CodeGenModule::MayBeEmittedEagerly(const ValueDecl *Global) {
   }
 
   if (const auto *FD = dyn_cast<FunctionDecl>(Global)) {
     if (FD->getTemplateSpecializationKind() == TSK_ImplicitInstantiation)
       // Implicit template instantiations may change linkage if they are later
       // explicitly instantiated, so they should not be emitted eagerly.
       return false;
   }
-  if (const auto *VD = dyn_cast<VarDecl>(Global))
+  if (const auto *VD = dyn_cast<VarDecl>(Global)) {
     if (Context.getInlineVariableDefinitionKind(VD) ==
         ASTContext::InlineVariableDefinitionKind::WeakUnknown)
       // A definition of an inline constexpr static data member may change
       // linkage later if it's redeclared outside the class.
       return false;
+    if (CXX20ModuleInits && VD->getOwningModule()) {
+      // For CXX20, module-owned initialisers need to be deferred, since it is
+      // not known at this point if they will be run for the current module or
+      // as part of the initializer for an imported one.
+      return false;
+    }
+  }
   // If OpenMP is enabled and threadprivates must be generated like TLS, delay
   // codegen for global variables, because they may be marked as threadprivate.
   if (LangOpts.OpenMP && LangOpts.OpenMPUseTLS &&
       getContext().getTargetInfo().isTLSSupported() && isa<VarDecl>(Global) &&
       !isTypeConstant(Global->getType(), false) &&
       !OMPDeclareTargetDeclAttr::isDeclareTargetDeclaration(Global))
     return false;
 
void CodeGenModule::EmitGlobal(GlobalDecl GD) {
   }
 
   // Defer code generation to first use when possible, e.g. if this is an inline
   // function. If the global must always be emitted, do it eagerly if possible
   // to benefit from cache locality.
   if (MustBeEmitted(Global) && MayBeEmittedEagerly(Global)) {
     // Emit the definition if it can't be deferred.
     EmitGlobalDefinition(GD);
     return;
   }
 
   // If we're deferring emission of a C++ variable with an
   // initializer, remember the order in which it appeared in the file.
   if (getLangOpts().CPlusPlus && isa<VarDecl>(Global) &&
       cast<VarDecl>(Global)->hasInit()) {
     DelayedCXXInitPosition[Global] = CXXGlobalInits.size();
     CXXGlobalInits.push_back(nullptr);
   }
if (!ImportedModules.insert(Import->getImportedModule()))
       break;
 
     // Emit debug information for direct imports.
     if (!Import->getImportedOwningModule()) {
       if (CGDebugInfo *DI = getModuleDebugInfo())
         DI->EmitImportDecl(*Import);
     }
 
+    // For CXX20 we are done - we will call the module initialiser for the
+    // imported module, and that will likewise call those for any imports it
+    // has.
+    if (CXX20ModuleInits)
+      break;
+
     // Find all of the submodules and emit the module initializers.
     llvm::SmallPtrSet<clang::Module *, 16> Visited;
     SmallVector<clang::Module *, 16> Stack;
     Visited.insert(Import->getImportedModule());
     Stack.push_back(Import->getImportedModule());
 
     while (!Stack.empty()) {
       clang::Module *Mod = Stack.pop_back_val();

clang/lib/Parse/ParseAST.cpp

for (bool AtEOF = P.ParseFirstTopLevelDecl(ADecl, ImportState); !AtEOF;
         return;
     }
   }
 
   // Process any TopLevelDecls generated by #pragma weak.
   for (Decl *D : S.WeakTopLevelDecls())
     Consumer->HandleTopLevelDecl(DeclGroupRef(D));
 
+  // For C++20 modules, the codegen for module initializers needs to be altered
+  // and to be able to use a name based on the module name.
+
+  // At this point, we should know if we are building a non-header C++20 module.
+  if (S.getLangOpts().CPlusPlusModules && !S.getLangOpts().IsHeaderFile &&
+      !S.getLangOpts().CurrentModule.empty()) {
+    // If we are building the module from source, then the top level module
+    // will be here.
+    Module *CodegenModule = S.getCurrentModule();
+    if (!CodegenModule)
+      // If we are building the module from a PCM file, then the module can be
+      // found here.
+      CodegenModule = S.getPreprocessor().getCurrentModule();
+    // If neither. then ....
+    assert(CodegenModule && "codegen for a module, but don't know which?");
+    S.getASTContext().setModuleForCodeGen(CodegenModule);
+  }
   Consumer->HandleTranslationUnit(S.getASTContext());
 
   // Finalize the template instantiation observer chain.
   // FIXME: This (and init.) should be done in the Sema class, but because
   // Sema does not have a reliable "Finalize" function (it has a
   // destructor, but it is not guaranteed to be called ("-disable-free")).
   // So, do the initialization above and do the finalization here:
   finalize(S.TemplateInstCallbacks, S);

clang/test/CodeGen/module-intializer-pmf.cpp

+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 %s \
+// RUN:    -emit-module-interface -o HasPMF.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 HasPMF.pcm \
+// RUN:  -S -emit-llvm -o - | FileCheck %s
+
+module;
+
+struct Glob {
+  Glob(){};
+};
+
+Glob G;
+
+export module HasPMF;
+
+export struct InMod {
+  InMod(){};
+};
+
+export InMod IM;
+
+module :private;
+
+struct InPMF {
+  InPMF(){};
+};
+
+InPMF P;
+
+// CHECK: define internal void @__cxx_global_var_init
+// CHECK: call void @_ZN4GlobC1Ev
+// CHECK: define internal void @__cxx_global_var_init
+// CHECK: call void @_ZNW6HasPMF5InPMFC1Ev
+// CHECK: define internal void @__cxx_global_var_init
+// CHECK: call void @_ZNW6HasPMF5InModC1Ev
+// CHECK: define void @_ZGIW6HasPMF
+// CHECK: store i8 1, ptr @_ZGIW6HasPMF__in_chrg
+// CHECK: call void @__cxx_global_var_init
+// CHECK: call void @__cxx_global_var_init
+// CHECK: call void @__cxx_global_var_init

clang/test/CodeGen/module-intializer.cpp

+// RUN: rm -rf %t
+// RUN: split-file %s %t
+// RUN: cd %t
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.cpp \
+// RUN:    -emit-module-interface -o N.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 N.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-N
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 O.cpp \
+// RUN:    -emit-module-interface -o O.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 O.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-O
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-part.cpp \
+// RUN:    -emit-module-interface -o M-part.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M-part.pcm -S \
+// RUN: -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-P
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.cpp \
+// RUN: -fmodule-file=N.pcm -fmodule-file=O.pcm -fmodule-file=M-part.pcm \
+// RUN:    -emit-module-interface -o M.pcm
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 M.pcm -S -emit-llvm \
+// RUN:  -o - | FileCheck %s --check-prefix=CHECK-M
+
+// RUN: %clang_cc1 -triple %itanium_abi_triple -std=c++20 useM.cpp \
+// RUN: -fmodule-file=M.pcm -S -emit-llvm  -o - \
+// RUN: | FileCheck %s --check-prefix=CHECK-USE
+
+//--- N-h.h
+
+struct Oink {
+  Oink(){};
+};
+
+Oink Hog;
+
+//--- N.cpp
+
+module;
+#include "N-h.h"
+
+export module N;
+
+export struct Quack {
+  Quack(){};
+};
+
+export Quack Duck;
+
+// CHECK-N: define internal void @__cxx_global_var_init
+// CHECK-N: call void @_ZN4OinkC1Ev
+// CHECK-N: define internal void @__cxx_global_var_init
+// CHECK-N: call void @_ZNW1N5QuackC1Ev
+// CHECK-N: define void @_ZGIW1N
+// CHECK-N: store i8 1, ptr @_ZGIW1N__in_chrg
+// CHECK-N: call void @__cxx_global_var_init
+// CHECK-N: call void @__cxx_global_var_init
+
+//--- O-h.h
+
+struct Meow {
+  Meow(){};
+};
+
+Meow Cat;
+
+//--- O.cpp
+
+module;
+#include "O-h.h"
+
+export module O;
+
+export struct Bark {
+  Bark(){};
+};
+
+export Bark Dog;
+
+// CHECK-O: define internal void @__cxx_global_var_init
+// CHECK-O: call void @_ZN4MeowC2Ev
+// CHECK-O: define internal void @__cxx_global_var_init
+// CHECK-O: call void @_ZNW1O4BarkC1Ev
+// CHECK-O: define void @_ZGIW1O
+// CHECK-O: store i8 1, ptr @_ZGIW1O__in_chrg
+// CHECK-O: call void @__cxx_global_var_init
+// CHECK-O: call void @__cxx_global_var_init
+
+//--- P-h.h
+
+struct Croak {
+  Croak(){};
+};
+
+Croak Frog;
+
+//--- M-part.cpp
+
+module;
+#include "P-h.h"
+
+module M:Part;
+
+struct Squawk {
+  Squawk(){};
+};
+
+Squawk parrot;
+
+// CHECK-P: define internal void @__cxx_global_var_init
+// CHECK-P: call void @_ZN5CroakC1Ev
+// CHECK-P: define internal void @__cxx_global_var_init
+// CHECK-P: call void @_ZNW1M6SquawkC1Ev
+// CHECK-P: define void @_ZGIW1MWP4Part
+// CHECK-P: store i8 1, ptr @_ZGIW1MWP4Part__in_chrg
+// CHECK-P: call void @__cxx_global_var_init
+// CHECK-P: call void @__cxx_global_var_init
+
+//--- M-h.h
+
+struct Moo {
+  Moo(){};
+};
+
+Moo Cow;
+
+//--- M.cpp
+
+module;
+#include "M-h.h"
+
+export module M;
+import N;
+export import O;
+import :Part;
+
+export struct Baa {
+  int x;
+  Baa(){};
+  Baa(int x) : x(x) {}
+  int getX() { return x; }
+};
+
+export Baa Sheep(10);
+
+// CHECK-M: define internal void @__cxx_global_var_init
+// CHECK-M: call void @_ZN3MooC1Ev
+// CHECK-M: define internal void @__cxx_global_var_init
+// CHECK-M: call void @_ZNW1M3BaaC1Ei
+// CHECK-M: declare void @_ZGIW1O()
+// CHECK-M: declare void @_ZGIW1N()
+// CHECK-M: declare void @_ZGIW1MWP4Part()
+// CHECK-M: define void @_ZGIW1M
+// CHECK-M: store i8 1, ptr @_ZGIW1M__in_chrg
+// CHECK-M: call void @_ZGIW1O()
+// CHECK-M: call void @_ZGIW1N()
+// CHECK-M: call void @_ZGIW1MWP4Part()
+// CHECK-M: call void @__cxx_global_var_init
+// CHECK-M: call void @__cxx_global_var_init
+
+//--- useM.cpp
+
+import M;
+
+int main() {
+  return Sheep.getX();
+}
+
+// CHECK-USE: declare void @_ZGIW1M
+// CHECK-USE: define internal void @_GLOBAL__sub_I_useM.cpp
+// CHECK-USE: call void @_ZGIW1M()