My rule of thumb is: If an optimization reduces memory accesses, it is important today. Register allocation fits that pattern, because the alternative is to spill values to memory.

Disclaimer: That rule is restricted to fast processors, not low-power embedded stuff.

Inlining is not that important for speed itself. It rather is an optimization booster, which makes many other optimization much more effective. If your other optimizations are crap, then inlining will not help much, because the call overhead is not that big.

Registers are also the nodes in the DAG of evaluation. Superscalar execution relies on having multiple edges active over time. Thus, good register allocation won't have bottlenecks, and won't make the evaluation DAG look like a series of linked lists.

There's a nice overview for people with a passing interest here: http://www.lighterra.com/papers/basicinstructionscheduling/

How did I go so far without hearing the path of execution described as a DAG. Damn that's a useful concept.

I might start prototyping some things in DAG notation just to avoid ever forgetting this conceptual abstraction.

Expressions are DAGs after common subexpression elimination. DAGs are what you get when you symbolically evaluate expressions on a stack machine without backward edges in control flow. Leave out the backward edges and the phi nodes they create, and you get DAGs from SSA form as well (but sequencing has information that you lose).

You might be interested in "FIRM—A Graph-Based Intermediate Representation" http://pp.ipd.kit.edu/publication.php?id=braun11wir

(I'm one of the authors)

Inlining makes for better register allocation :-)

Because you don't need registers for the function call ceremony?

Yes, and because you don't have to spill the arguments to the stack. Also, you optimize across the function call boundary.

Because you can allocate registers in a way that is particular to a specific call's context, rather than in the generic context of a called function.