Sethi–Ullman algorithm: Difference between revisions

Revision as of 23:13, 11 May 2005

Latest revision as of 15:13, 24 February 2025

(48 intermediate revisions by 39 users not shown)

Line 1:

{{Short description|Algorithm for minimising register usage}}

When [[Code_generation|generating code]] for arithmetic expressions, the [[compiler]] has to decide which is the best way to translate the expression in terms of number of instructions used as well as number of registers needed to evaluate a certain subtree (especially if free registers are scarce). The so called '''Sethi-Ullman algorithm''' (also known as [[Sethi-Ullman numbering]]) fulfills the property of producing code which needs the least number of instructions possible as well as the least number of storage references (under the assumption that at the most [[commutativity]] and [[associativity]] apply to the operators used, but laws like <math>a * b + a * c = a * (b + c)</math> do not hold). Please note that the algorithm succeeds as well if neither [[commutativity]] nor [[associativity]] hold for the expressions used, and therefore arithmetic transformations can not be applied.

In [[computer science]], the '''Sethi–Ullman algorithm''' is an [[algorithm]] named after [[Ravi Sethi]] and [[Jeffrey D. Ullman]], its inventors, for translating [[abstract syntax tree]]s into [[machine code]] that uses as few [[Processor register|registers]] as possible.

==Overview==

==Simple Sethi-Ullman algorithm==

When [[Code_generationcode generation (compiler)|generating code]] for arithmetic expressions, the [[compiler]] has to decide which is the best way to translate the expression in terms of number of instructions used as well as number of registers needed to evaluate a certain subtree. (especiallyEspecially ifin the case that free registers are scarce)., Thethe so[[order calledof '''Sethi-Ullmanevaluation]] algorithm'''can (alsobe knownimportant asto the length of the generated code, because different orderings may lead to larger or smaller numbers of intermediate values being [[Sethi-Ullmanregister numberingallocation|spilled]]) fulfillsto thememory propertyand ofthen producingrestored. The Sethi–Ullman algorithm (also known as '''Sethi–Ullman numbering''') produces code which needs the least number offewest instructions possible as well as the least number offewest storage references (under the assumption that at the most [[commutativity]] and [[associativity]] apply to the operators used, but distributive laws likei.e. <math>a * b + a * c = a * (b + c)</math> do not hold). Please note that theThe algorithm succeeds as well if neither [[commutativity]] nor [[associativity]] hold for the expressions used, and therefore arithmetic transformations can not be applied. The algorithm also does not take advantage of common subexpressions or apply directly to expressions represented as general directed acyclic graphs rather than trees.

The '''simple Sethi-Ullman algorithm''' works as follows (for a [[RISC|load-store architecture]]):

==Simple Sethi-UllmanSethi–Ullman algorithm==

The '''simple Sethi-UllmanSethi–Ullman algorithm''' works as follows (for a [[RISC|load-/store architecture]]):

# Traverse the [[abstract syntax tree]] in pre- or postorder

## For every leaf node, if it is a non-constant leaf nodeleft-child, assign a 1 (i.e. 1 register is needed to hold the variable/field/etc.), otherwise assign a 0 (it is a non-constant right child or constant leaf node (RHS of an operation – literals, values)).

## For every non-leaf node ''n'', assignif the numberleft ofand registers needed to evaluate the respectiveright subtrees ofrespectively ''n''.need Ifdifferent the numbernumbers of registers needed in the left subtree (''l'') areand not equal to the number of registers needed in the right subtree (''r''), thethen number of registers needed for the current nodeassign max(''nl'' is ,&nbsp;''max(l, r)''.), Ifotherwise assign ''l == r'', then the number of registers needed for the current node is ''l &nbsp;+ &nbsp;1''.

# To emit code, if the subtrees need different numbers of registers, evaluate the subtree needing the most registers first (since the register needed to save the result of one subtree may make the other one [[Register spilling|spill]]), otherwise the order is irrelevant.

# Code emission

## If the number of registers needed to compute the left subtree of node ''n'' is bigger than the number of registers for the right subtree, then the left subtree is evaluated first (since it may be possible that the one more register needed by the right subtree to save the result makes the left subtree [[Register spilling|spill]]). If the right subtree needs more registers than the left subtree, the right subtree is evaluated first accordingly. If both subtrees need equal as much registers, then the order of evaluation is irrelevant.

===Example===

For an arithmetic expression <math>a = (b + c) + f * g)*(d + 3)</math>, the [[abstract syntax tree]] looks like this:

=

Line 20 ⟶ 23:

+ +

/ \ / \

b/ c\ d 3

+ *

/ \ / \

To continue with the algorithm, we need only to examine the arithmetic expression <math>(b + c) * (d + 3)</math>, i.e. we only have to look at the right subtree of the assignment '=':

b c f g

To continue with the algorithm, we need only to examine the arithmetic expression <math>(b + c + f * g) * (d + 3)</math>, i.e. we only have to look at the right subtree of the assignment '=':

*

Line 29 ⟶ 34:

+ +

/ \ / \

b/ c\ d 3

+ *

/ \ / \

Now we start traversing the tree (in preorder for now), assigning the number of registers needed to evaluate each subtree (note that the last summand in the expression <math>(b + c) * (d + 3)</math> is a constant):

b c f g

Now we start traversing the tree (in preorder for now), assigning the number of registers needed to evaluate each subtree (note that the last summand in the expression <math>(b + c + f * g) * (d + 3)</math> is a constant):

*_'''2'''

Line 38 ⟶ 45:

+_'''2''' +_'''1'''

/ \ / \

b/ \ d_'''1''' c3_'''10'''d
+_'''1''' 3 *_'''01'''

/ \ / \

b_'''1''' c_'''0'''f_'''1''' g_'''0'''

From this tree it can be seen that we need 2 registers to compute the left subtree of the '*', but only 1 register to compute the right subtree. Nodes 'c' and 'g' do not need registers for the following reasons: If T is a tree leaf, then the number of registers to evaluate T is either 1 or 0 depending whether T is a left or a right subtree (since an operation such as add R1, A can handle the right component A directly without storing it into a register). Therefore we shall start to emit code for the left subtree first, because we might run into the situation that we only have 2 registers left to compute the whole expression. If we now computed the right subtree first (which needs only 1 register), we would then need a register to hold the result of the right subtree while computing the left subtree (which would still need 2 registers), therefore needing 3 registers concurrently. Computing the left subtree first needs 2 registers, but the result can be stored in 1, and since the right subtree needs only 1 register to compute, the evaluation of the epxressionexpression can do with only 2 registers left.

==Advanced Sethi-UllmanSethi–Ullman algorithm==

From this tree it can be seen that we need 2 registers to compute the left subtree of the '*', but only 1 register to compute the right subtree. Therefore we shall start to emit code for the left subtree first, because we might run into the situation that we only have 2 registers left to compute the whole expression. If we now computed the right subtree first (which needs only 1 register), we would then need a register to hold the result of the right subtree while computing the left subtree (which would still need 2 registers), therefore needing 3 registers concurrently. Computing the left subtree first needs 2 registers, but the result can be stored in 1, and since the right subtree needs only 1 register to compute, the evaluation of the epxression can do with only 2 registers left.

In an advanced version of the '''Sethi-UllmanSethi–Ullman algorithm''', the arithmetic expressions are first transformed, exploiting the algebraic properties of the operators used.

==See also==

==Advanced Sethi-Ullman algorithm==

*[[Strahler number]], the minimum number of registers needed to evaluate an expression without any external storage

In an advanced version of the '''Sethi-Ullman algorithm''', the arithmetic expressions are first transformed, exploiting the algebraic properties of the operators used.

*[[Ershov Number]], basically the same concept as Strahler number

==References==

*[http://portal.acm.org/{{citation.cfm?doid|title=321607.321620 The Generation of Optimal Code for Arithmetic Expressions] [[|first1=Ravi |last1=Sethi]],|author1-link=Ravi [[Sethi|first2=Jeffrey D. |last2=Ullman|J.author2-link=Jeffrey D. Ullman]], |journal=[[Journal of the [[Association for Computing Machinery|ACM]], Vol. |volume=17, No. |issue=4, October |year=1970, pp|pages=715–728|doi=10. 7151145/321607.321620|hdl=10338.dmlcz/101207|hdl-728access=free}}.

==External links==

*[httphttps://lambda.uta.edu/cse5317/fall02/notes/node40node43.html Code Generation for Trees]

*[http://portal.acm.org/citation.cfm?doid=321607.321620 The Generation of Optimal Code for Arithmetic Expressions] [[Ravi Sethi]], [[Jeffrey D. Ullman|J. D. Ullman]], Journal of the [[Association for Computing Machinery|ACM]], Vol. 17, No. 4, October 1970, pp. 715-728

*[http://lambda.uta.edu/cse5317/fall02/notes/node40.html Code Generation for Trees]

{{DEFAULTSORT:Sethi-Ullman algorithm}}

[[Category:Compiler construction]]

[[Category:Graph algorithms]]