Re:How do compilers optimize divisions?
by barrkel on Tuesday February 21, 2017 @05:23AM
(#13694600)
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/
Re:How do compilers optimize divisions?
by techdragon on Tuesday February 21, 2017 @05:56AM
(#13694708)
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.
Re:How do compilers optimize divisions?
by barrkel on Tuesday February 21, 2017 @07:57AM
(#13695083)
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)
Re:How do compilers optimize divisions?
by WalterBright on Tuesday February 21, 2017 @04:16AM
(#13694361)
Inlining makes for better register allocation :-)
Because you don't need registers for the function call ceremony?
Re:How do compilers optimize divisions?
by benchaney on Tuesday February 21, 2017 @04:44AM
(#13694457)
Yes, and because you don't have to spill the arguments to the stack. Also, you optimize across the function call boundary.
Re:How do compilers optimize divisions?
by WalterBright on Tuesday February 21, 2017 @09:25PM
(#13702381)
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.
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.