Are compilers allowed to merge nested virtual calls inside a "final" class?

Summary

The issue described is that even when a class is declared final, compilers like Clang and GCC often do not merge nested virtual calls into a single direct call. In the provided example, Base::Call invokes DerivedStatic::Call, which in turn invokes UserStatic::CallTyped. Despite UserStatic being final, compilers fail to eliminate the intermediate virtual dispatch. The key takeaway is that while the C++ standard permits this optimization (the “as-if” rule), practical constraints such as ABI compatibility, vtable layout constraints, and compiler optimization pass limitations prevent it from occurring automatically.

Root Cause

The inability to merge these calls stems from several distinct factors rooted in C++ language mechanics and compiler architecture:

VTable Layout Constraints: The vtable for DerivedStatic is defined by the base class hierarchy. Even if UserStatic is final, the vtable slot for Base::Call must point to a function compatible with the DerivedStatic signature. Changing this pointer to point directly to the final implementation might violate the Itanium ABI or MSVC ABI rules regarding vtable slot assignment.
Visibility of Final State: The compiler unit processing DerivedStatic often does not know that a derived class like UserStatic exists or is final. This knowledge is usually required at link time (via Link-Time Optimization, LTO), which may not be enabled or might not trigger this specific optimization.
Intermediate Function Complexity: If DerivedStatic::Call contains logic (like the reinterpret_cast in the example) that is semantically required, the compiler may treat the function body as opaque, preventing inlining of the final override back into the base caller.
ABI Breakage Concerns: Merging calls changes the instruction stream and stack usage. If any code relied on the existence of DerivedStatic::Call (e.g., for stack unwinding, profiling, or explicit address comparison), merging them would break that code.

Why This Happens in Real Systems

In real-world systems, compilers prioritize strict standard compliance and ABI stability over aggressive devirtualization in complex inheritance chains.

Separate Compilation: C++ relies heavily on separate compilation. DerivedStatic might be compiled into a library where the final implementation of UserStatic is unknown.
RTTI and Exception Handling: Virtual functions are tied to type information. Merging calls can complicate exception handling and RTTI lookups, which rely on specific frame layouts.
Compiler Heuristics: Compilers use heuristics to decide when to devirtualize. A chain of virtual calls (Base -> Derived -> Final) is more expensive to analyze than a direct call. If the heuristic decides the gain is marginal or the risk is high, it skips the optimization.

Real-World Impact

Failing to merge these calls results in measurable performance degradation in high-throughput systems.

Increased Latency: Each virtual call involves a pointer indirection (vtable lookup). Two virtual calls double the memory access latency compared to a direct call.
Pipeline Stalls: Indirect jumps are hard for CPU branch predictors, leading to pipeline flushes and reduced instructions-per-cycle (IPC).
Code Bloat: Generating distinct trampolines or thunks for every layer of inheritance increases the binary size.
Missed Devirtualization Opportunities: In scenarios like Message Passing or Event Systems (similar to the user’s dynamic typesystem), nested virtual calls are common. Without merging, these hot paths remain slow, preventing the system from scaling.

Example or Code

The user provided a valid C++ example demonstrating the structure. Below is the code block strictly containing the executable logic as requested.

#include 

struct Base {
    virtual void Call(void*) const = 0;
};

struct DerivedStatic : public Base {
private:
    void Call(void* pData) const override final {
        CallTyped(*reinterpret_cast(pData));
    }
    virtual void CallTyped(int data) const = 0;
};

struct UserStatic final : public DerivedStatic {
private:
    void CallTyped(int data) const override {
        std::cout <Call(&value);
    return 0;
}

How Senior Engineers Fix It

Senior engineers address this by either forcing the compiler’s hand or redesigning the abstraction to avoid the cost entirely.

Use Link-Time Optimization (LTO): Enabling -flto (GCC/Clang) or /LTCG (MSVC) allows the compiler to see the entire program, including the final definition of UserStatic, and aggressively inline the call.
Finalize at the Base Level: If the hierarchy allows, declare the top-level derived class (UserStatic) as the only instantiation or use CRTP (Curiously Recurring Template Pattern) to statically bind the call at compile time, eliminating virtual dispatch entirely.
```
template 
struct Base {
    void Call(void* data) const {
        static_cast(this)->CallTyped(*reinterpret_cast(data));
    }
};
```
Explicit Inlining for Hot Paths: For performance-critical sections, bypass the virtual call by using static_cast to the final type if the type is known, or by providing a non-virtual entry point.
Profile-Guided Optimization (PGO): Use PGO to guide the compiler to merge calls based on actual runtime data, ensuring the optimization is applied only where it matters.

Why Juniors Miss It

Junior engineers often misunderstand the relationship between source code syntax and generated machine code.

Over-reliance on final: Juniors assume that final guarantees inlining or direct calls. While final allows optimization, it does not mandate it; the compiler must still respect ABI rules and separate compilation boundaries.
Ignoring ABI Constraints: They often lack a deep understanding of the Itanium ABI (used by GCC/Clang on Linux) or MSVC ABI, which dictate how vtables are laid out in memory. They don’t realize that modifying vtable entries dynamically is risky.
Conceptual Model of Virtual Calls: Many juniors view virtual calls as “fast enough” or fail to recognize nested virtual calls (a chain of dispatches) as a specific anti-pattern (“double dispatch”) that requires manual intervention to fix.
Lack of Assembly Inspection: They rarely inspect the disassembly (objdump or Compiler Explorer) to see that the expected inlining did not occur, assuming the compiler did its best without verification.