インライン化とループ変換の識別

You know common optimizations, can read optimized assembly, and reconstruct logic. Two transformations cause the most confusion: function inlining and loop reshaping.

Recognizing them keeps your reconstruction accurate.

Inlining replaces a function call with the callee's body, eliminating call overhead.

In the binary the original function may vanish entirely; its code appears merged into every caller.

Signs of inlining:

• A helper you expect to see as a separate function never appears
• The same instruction pattern repeats in many callers
• No matching call where the source had one

Loop unrolling executes several iterations per loop pass to cut branch overhead.

A loop that should run 4 times may show 4 copies of the body and no inner branch.

For unknown trip counts the compiler unrolls in chunks (say 4 at a time) plus a remainder loop for leftovers.

Seeing a big block followed by a small single-step loop is the classic partial-unroll fingerprint.

Vectorization processes multiple data elements at once using SIMD registers like XMM/YMM.

Instructions such as movdqu, paddd, or addps signal that a scalar loop was turned into vector operations.

When you see SIMD or unrolled bodies, mentally collapse them back to a single scalar loop. Four parallel adds equal a loop summing four elements.

Document the simple intent, not the optimized shape.

Compilers hoist computations that do not change across iterations out of the loop. A multiplication you expect inside the loop may appear before it.

Knowing this prevents you from misreading where work happens.

Multiplications inside loops are often replaced by cheaper additions (strength reduction). An index times stride becomes a pointer that increments by stride each pass.

Recognize add ptr, 8 as 'next element' rather than literal pointer math.

Decompilers (Ghidra, Hex-Rays) often re-roll loops and de-inline automatically, presenting cleaner pseudocode. Use them, but verify against the assembly when behavior matters.

When a function's last action is a call, the compiler may turn it into a jump instead of call-then-return, reusing the current frame.

Seeing a jmp to another function at the end of a routine, rather than a call followed by ret, is the signature of a tail call.

You expected to see a small helper function but it never appears as its own routine; instead its code is duplicated inside every caller. What optimization is this?

You can now see through aggressive optimizations:

• Inlining merges callees into callers
• Unrolling and vectorization fan loop bodies into parallel work
• Invariant motion and strength reduction relocate or cheapen operations

Collapse these back to simple source intent in your reconstruction.