References:
Most compiler optimizations are performed on procedures one at a time. We refer to such analyses as intraprocedural. These analyses conservatively assume that procedures invoked may alter the state of all the variables visible to the procedures and that they may create all possible side effects, such as modifying any of the variables visible to the procedure or generating exceptions that cause the unwinding of the call stack.
Intraprocedural analysis is thus relatively simple, albeit imprecise.
Some optimizations do not need interprocedural analysis, while others may yield almost no useful information without it.
An interprocedural analysis operates across an entire program, flowing information from the caller to its callees and vice versa.
inline procedures: only applicable if we know the target of the procedure call; will increase code size exponentially.
If procedures are invoked indirectly through a pointer or via the method dispatch mechanism prevalent in object-oriented programming, analysis of the program’s pointers or references can in some cases determine the targets of the indirect invocations. If there is a unique target, inlining can be applied. Even if a unique target is determined for each procedure invocation, inlining must be applied judiciously. In general, it is not possible to inline recursive procedures directly, and even without recursion, inlining can expand the code size exponentially.
Reference:
The idea:
Need to handle:
If you could revise
the fundmental principles of
computer system design
to improve security...
... what would you change?