[C++20] [Modules] Do we need the concept of `key function` for class defined in module purview?

[ChuanqiXu9]

See llvm/llvm-project#70585 for the motivation issue.

Simply, the current clang's behavior violates itanium ABI 5.2.3:

The virtual table for a class is emitted in the same object containing the definition of its key function, i.e. the first non-pure virtual function that is not inline at the point of class definition.

But there are opinions about: is the concept of key function necessary after we introducing modules? So I bring the issue here.

My thought about the key function is that: in the headers model, the class may be defined in many TUs, then we need to find a TU to generate the virtual table. But after we introducing modules, if we define the class is defined is a module purview, we can get the TU to generate the virtual table naturally.

My understanding to the issues is: while the original old rule works, maybe it is better to have some new rules with the new features technically.

[rjmccall]

I completely agree. I opened PR #171 to address this, as well as several related issues I saw while updating this section.

[ChuanqiXu9]

Since #171 is merged, we can close this.

[jicama]

Why does this not apply to all vague linkage entities defined in module purview? Shouldn't inline variables and functions also be emitted in the module unit that defines them?
[oops, didn't mean to reopen, but I guess it's fine for the moment]

[rjmccall]

I think you're right that we could, at least for non-templated entities. It's an interesting question whether we should.

If we eagerly emit a strong definition and then don't actually need it (e.g. because we inline every use of it), we'll end up having to hope the linker dead-strips it. The linker can probably do that reliably unless it's linking a shared library, in which case it probably can't do it at all. (Unfortunately, modules still don't tell us anything about how the module and its dependencies are assembled in the overall program, so default visibility still has to be the default.)

On the other hand, of course, if we don't eagerly emit a strong definition, we're still stuck in the world of today where compilers waste huge amounts of time and energy emitting thousands of redundant definitions of inline functions into every translation unit, especially in unoptimized builds. But my sense is that most of that overhead in practice comes from templates, which modules don't help us with at all.

I don't know. Changing the ABI here would be a huge change. It's probably our only shot to make a significant dent in the redundant emission problem, though.

[ChuanqiXu9]

I feel this is a pretty complex topic. For a similar case, WG21 choose to make in-class member functions in module purview to be non implicitly inline.

Also the inlined entities in module purview are helpful for optimizations. For this example:

export moudle a;
export int a() {
    return 43;
}

Currently, the consumer of module a can't inline the body of function a unless LTO is enabled. This raised some concern about performance when I share the topic. But I said, "it is still OK to mark function a as inline if you really want that". But if we force all inline functions to be defined in the module purview, the users lose the chance to control the inlining. (I know it is known as bad idea to control compiler optimization in the user side).

Then for templates, maybe it will be an compile-time optimization to only emit the implicitly instantiated templates in the module unit. But we don't have a feeling how good will it be. From the perspective of compile-time optimization, maybe we should try to experiment this with a flag as an compiler extension to get a feeling. Then we can make further proposals.

[jicama]

For a similar case, WG21 choose to make in-class member functions in module purview to be non implicitly inline.

Indeed. I don't remember the rationale for that change.

But if we force all inline functions to be defined in the module purview, the users lose the chance to control the inlining. (I know it is known as bad idea to control compiler optimization in the user side).

I don't understand your point; an inline function can be emitted out-of-line and also still inlined.

Then for templates, maybe it will be an compile-time optimization to only emit the implicitly instantiated templates in the module unit. But we don't have a feeling how good will it be. From the perspective of compile-time optimization, maybe we should try to experiment this with a flag as an compiler extension to get a feeling. Then we can make further proposals.

The CMI could indicate which imported vague linkage entities were emitted in the module unit .o, so importers don't need to emit them as well? That would still require consistency between the compilations that produce the CMI and the .o, which might not be the same compiler invocation.