[C++20] [Modules] Named Module Units would generate initializers unconditionally

[ChuanqiXu9]

For, the following line

//--- A.cpp
export module A;

and option

clang++ -std=c++20 A.cppm --precompile -o A.pcm
clang++ -std=c++20 A.pcm -S -emit-llvm -o A.ll

It would generate:

@_ZGIW1A__in_chrg = internal global i8 0, align 1
@llvm.global_ctors = appending global [1 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 65535, ptr @_ZGIW1A, ptr null }]

define void @_ZGIW1A() #0 section ".text.startup" {
entry:
  %0 = load i8, ptr @_ZGIW1A__in_chrg, align 1
  %guard.uninitialized = icmp eq i8 %0, 0
  br i1 %guard.uninitialized, label %init, label %exit, !prof !4

init:                                             ; preds = %entry
  store i8 1, ptr @_ZGIW1A__in_chrg, align 1
  br label %exit

exit:                                             ; preds = %init, %entry
  ret void
}

This is bad. A.cppm has nothing but it generates actual codes. It would be worse if we import something:

//--- B.cppm
export module B;
import A;

Then the generated code would be:

@_ZGIW1B__in_chrg = internal global i8 0, align 1
@llvm.global_ctors = appending global [1 x { i32, ptr, ptr }] [{ i32, ptr, ptr } { i32 65535, ptr @_ZGIW1B, ptr null }]

declare void @_ZGIW1A()

define void @_ZGIW1B() #0 section ".text.startup" {
entry:
  %0 = load i8, ptr @_ZGIW1B__in_chrg, align 1
  %guard.uninitialized = icmp eq i8 %0, 0
  br i1 %guard.uninitialized, label %init, label %exit, !prof !4

init:                                             ; preds = %entry
  store i8 1, ptr @_ZGIW1B__in_chrg, align 1
  call void @_ZGIW1A()
  br label %exit

exit:                                             ; preds = %init, %entry
  ret void
}

Yeah, it calls the initializer from A. This is a call across TUs so it can't be inlined without LTO. As a result, the startup performance may decrease if there are many many imports.

This is not about the correctness, though.

[llvmbot]

@llvm/issue-subscribers-c-20

[llvmbot]

@llvm/issue-subscribers-clang-modules

[kaimfrai]

I just ran into this (Clang 17) and was about to open a new issue, but found this instead, so I'd like to leave my comment on the matter here:

While inspecting the disassemblies of a program generated with meta-programming and one that's handwritten and does exactly the same, I noticed the following: Due to the meta-programming facilities being in modules, the first disassembly is filled with module initializers that effecitively do nothing. Not only does this result in consistently ever so slightly worse total runtimes and cache statistics (valgrind), it also results in much larger binary sizes (3.5 times which until now I attributed to the long mangled names from the templates). The disassembly itself has almost 5 times as many lines.

I could observe this with -flto=thin and -flto=full as well as with the linkers lld and mold. So in short: Startup performance is hit, binary sizes bloat up and it's not mitigated by LTO. Ideally, if the module initializer does nothing, there isn't one to begin with and perhaps linking against the object file could be omited, as it does not contain any meaningful information. I imagine this could also help build speeds.

[ChuanqiXu9]

Sorry for forgetting to update this.

The consensus is that the initializer should be emitted all the way. Since this is part of BMI standard. Otherwise the object files compiled by clang won't be linked with object files compiled by GCC.

But the callers are free to elide the call to the initializers if the compiler makes sure that it is not necessary. (Not implemented in clang yet.)

For the runtime performance and code size issues, I feel your use case may be too special. I've tested modules with our server use cases. The performance looks good and code size goes down (except BMI size).

The conclusion is that this may be optimized but I guess it can't achieve your goals.