Repository navigation
Codegen Patterns
Use compiler output as evidence about the original C++ source shape. These patterns are clues, not universal rules: verify with the target compiler, flags, ABI, and surrounding control flow. The examples are minimal illustrations rather than recovered project code.
- Codegen Patterns Od — argument evaluation, copies, comparisons, and control flow.
- Codegen Patterns O2 — optimized loops, stores, and branch structure.
- Codegen Patterns EH — object lifetimes, catch types, and unwind state.
Symptom: Several functions differ only in register allocation or constant materialization inside an inlined library reader. Likely source: the header's inline body differs subtly from the SDK implementation. Example: use the SDK's member-field reads and casts directly rather than copying a field into a local.
std::uint32_t read() { return position; }Symptom: A virtual destructor begins with member destruction and has no vtable-pointer store. Likely source: the destructor was compiler-generated implicitly. An explicit empty destructor can introduce an extra vptr store.
struct Item {
virtual ~Item() = default; // Explicit declaration may change emitted code.
};Compare against an actually implicit destructor by omitting the declaration when the class's ABI and ownership permit it.
Symptom: An unexpected security-cookie prologue or a local struct placed high in the stack frame. Likely source: a local contains a character array, or is a plain scalar struct whose address is taken, causing MSVC's /GS buffer treatment. A typed constructor or a non-POD class layout can change that classification. Avoid using character arrays for padding when the target's layout does not contain them.
CRI units built with VC9 can show source clues unlike game code compiled by MSVC 14.16. For example, a dead parameter load may come from a self-comparison, and local stack slots may change when local names change. Treat these as VC9-specific observations rather than general C++ rules.