Questions: Procedure Inlining Optimization

Question 1

A compiler inlines the call `square(5)`, replacing it with `5 * 5` in the caller. What optimization is most likely to follow immediately?

• A. Dead code elimination removes the now-unreachable square function definition
• B. Constant folding reduces `5 * 5` to `25` at compile time
• C. Register allocation improves because one fewer function call means fewer callee-saved registers
• D. Loop unrolling becomes possible because the inlined body reveals a hidden iteration

Answer: (B)

Once the function is inlined and the constant argument 5 is propagated into the function body, constant folding can evaluate `5 * 5 = 25` at compile time — producing a constant result with no runtime computation at all. This chain of optimizations (inline → constant propagation → constant folding) is impossible across a call boundary because the compiler cannot see inside the called function to propagate values through it. Option A (dead code elimination of the function definition) may occur as a secondary effect, but the immediate downstream win is constant folding on the inlined body.

Question 2

A function called from 50 different sites is aggressively inlined everywhere. What is the primary risk that could make this slower than not inlining?

• A. The program stack grows too large because inlined code has no stack frame discipline
• B. Inlined code cannot be shared across call sites, leading to subtle behavioral differences
• C. Code size grows 50x, increasing instruction cache pressure and potentially causing more cache misses
• D. Register allocation becomes impossible when the inlined function has more than 4 local variables

Answer: (C)

Every inlining decision copies the function body, so inlining a function at 50 call sites creates 50 copies in the binary. Larger code means the instruction cache must hold more distinct instructions. If the working set exceeds the cache size, the CPU must fetch instructions from main memory more frequently — a severe performance penalty that can dwarf the savings from eliminating call overhead. This is the fundamental tension in inlining heuristics: the benefit (enabling downstream optimizations, eliminating call cost) must be weighed against the risk of cache thrashing from code bloat.

Question 3

The primary benefit of procedure inlining is often not the elimination of call overhead itself, but enabling subsequent optimizations like constant propagation and dead code elimination that become visible only after inlining.

• T. True
• F. False

Answer: True

Call overhead (stack manipulation, register saves, jumps) is typically a small cost — a few nanoseconds. The larger win is that inlining expands the optimizer's view: constant arguments can be propagated into the function body, dead branches conditional on those constants can be eliminated, and common subexpressions between caller and callee become visible. A call to `square(5)` saves very little by avoiding a jump; it saves significantly more when inlining enables `25` to appear directly in the code with no multiplication at runtime.

Question 4

Recursive functions are ideal candidates for inlining because their repeated structure creates many opportunities for constant propagation and loop optimization.

• T. True
• F. False

Answer: False

Recursive functions generally cannot be fully inlined because doing so would require infinite copies of the function body. Some compilers inline recursion to a fixed depth (e.g., 2–3 levels), but beyond that the recursion must still be handled with actual calls. Additionally, deeply inlined recursive bodies quickly explode in code size, causing exactly the cache pressure problems that make aggressive inlining counterproductive. Compilers typically exclude recursive functions from standard inlining heuristics or treat them as a special case.

Question 5

Why is procedure inlining typically performed early in the compiler's optimization pipeline rather than as one of the last passes?

Model answer: Inlining is performed early because it creates new opportunities for downstream optimization passes. Once a function body is inlined, constant propagation, dead code elimination, common subexpression elimination, and loop optimizations can all operate on the combined caller-callee code — finding redundancies that were invisible across the function boundary. If inlining were done late, after these passes had already run, the compiler would miss all those secondary optimizations. The value of inlining compounds: it doesn't just save call overhead, it sets up a cascade of further improvements that need subsequent passes to exploit.

This sequencing principle — perform transformations that expand the visible code early, then run analysis-and-reduction passes — is a general compiler design pattern. Inlining is a code-expanding transformation that trades code size for optimization opportunity, and that opportunity is only captured if the reducing passes (constant propagation, DCE, CSE) run afterward on the expanded code.