Class 31: Canonicalizing trees, continued

Held Friday, November 20, 1998

Handouts

• I've made some updates to the description of the final project to incorporate Jamal's suggestions.
• I'm starting to make sample code files available.

Notes

• Don't forget to get me topics and times for your presentations.
  • One group has chosen a topic: garbage collection.
  • I'd also be happy to hear debates on the old topics, now that you have more information.
• Next Monday, we'll look at basic blocks and conditional branches.
• Next Wednesday, we'll discuss the interpreter I've written for ``straight-line IRT''.

Review

Canonical IRTs

• Canonical IRTs do not contain SEQ or ESEQ. These are handled by putting the canonical IRTs in a sequence.
• Canonical trees restrict the use of CALL, so that each CALL is only used in a MOVE (which stores the result somewhere) or EXP (which throws away the result).
• Note that we do not need the ``spine'' I suggested. Rather, we need to make sure that we ``bubble up'' all the sequencing nodes to the top.

Techniques

• If we know that s can be executed before e1 is evaluated, as in BINOP(plus, ESEQ(s,e1), e2), we can move the ESEQ to the top.
• If we know that e1 must be evaluated before s is executed, as in BINOP(plus, e1, ESEQ(s,e2)), then we must create a new temporary, MOVE e1 to that temporary, and then put stuff in the right sequence.

Canonicalization, Revisited

Independence

• The second technique leads to some unnecesarily big trees. If the statement (s) does not affect the value of the expression (e1), then we can safely do s first without augmenting the tree.
• When is it safe? For example, if the expression is a constant or the statement does nothing.
• Appel says that a statement and expression commute if the statement has no side-effects that can alter the result produced by e (and, conversely, the expression has no side effects that can alter the effects of the statement).
• It may be impossible to determine at compile time whether a statement and expression commute. For example, do MOVE(MEM(TEMP(1)),CONST(1)) and MEM(TEMP(2)) commute? Not if TEMP(1) and TEMP(2) contain the same value (which is often only possible to determine at run time).
• If we can determine that a statement and expression do commute, then we can do simpler translations.
• For example, BINOP(op, e1, ESEQ(s, e2)) can be rewritten as ESEQ(s, BINOP(op, e1, e2)) if s and e1 commute.

More Sequencing

• What are some of the other intersting things that sequence nodes can interact with?
  • MEM
  • JUMP
  • CJUMP
  • MOVE
  • CALL
• We'll consider each in turn (sorry, I'm not giving away the answers).

Calls

• We've handled the sequencing part of canonicalization, but not the calls (except in relation to sequencing).
• Basically, any CALL that is not used in a legal format must be translated.
  • Start with: CALL(fun,args)
  • Generate: ESEQ(MOVE(TEMP(t), CALL(fun,args)), TEMP(t))
• You need to be careful on the recursion.

Examples

• Consider the C/Java fragment A[++i] = i.
  • This might be written in Tiger as the fragment
    A[(i = i + 1; i)] = i
    (ugly, isn't it).
  • What IRT should we generate?
  • How do we canonicalize it?

History

• Created Friday, November 20, 1998. Some parts filled in from the previous day's class, but mostly new.
• On Monday, November 23, 1998, moved a short example to the next outline.