Advanced Compilers - Code Generation 3 - Lecture Slides | EECS 583, Study notes of Electrical and Electronics Engineering

Download Advanced Compilers - Code Generation 3 - Lecture Slides | EECS 583 and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

EECS 583 – Lecture 14 Code Generation III

University of Michigan March 4, 2002

• 1 -

Rest of the semester plan

Y

7 more weeks

March 4, 6 - Scheduling

March 11, 13 – Register allocation

March 18, 20 – Groups 1 and 2

March 25, 27 – Exam and Group

April 1, 3 – Groups 4 and 1

April 8, 10 – Groups 2 and 3

April 15, 17 – Group 4 and catchup

Finals week – Project presentations

y

Schedule appt with me

Y

Group presentations

30 min per person covering 1-2 papers, 3-4 talks per class

Y

Exam

March 25 in class, 2 hr exam, open book/notes

Covers up through register allocation

• 3 -

Lstart in a superblock (last time)

Y

Not a single Lstart any more

1 per exit branch (Lstart is a vector!)

Exit branches have probabilities

1

3

1

1 2

op

Estart

Lstart0 Lstart

Exit0 (25%)

Exit1 (75%)

• 4 -

Operation priority in a SB (last time)

Y

Priority – Dependence height and speculative yield

Height from op to exit * probability of exit

Sum up across all exits in the superblock

Priority(op) = SUM(Probi * (MAX_Lstart – Lstarti(op) + 1))

valid late times for op

1

3

1

Exit0 (25%)

1 2

op

Lstart0 Lstart1 Priority

Exit1 (75%)

• 6 -

Conservative approach to control deps

Superblock

• Make branches barriers, nothing moves above or below branches * Schedule each BB in SB separately * Sequential schedules * Whole purpose of a superblock is lost

1: r1 = r2 + r32: r4 = load(r1)3: p1 = cmpp(r3 == 0)4: branch p1 Exit15: store (r4, -1)6: r2 = r2 – 47: r5 = load(r2)8: p2 = cmpp(r5 > 9)9: branch p2 Exit

Note: Control flow in red bold

• 7 -

Upward code motion across branches

Y

Restriction 1a (register op)

»

The destination of op is not inliveout(br)

»

Wrongly kill a live value

Y

Restriction 1b (memory op)

»

Op does not modify the memory

»

Actually live memory is whatmatters, but that is often toohard to determine

Y

Restriction 2

»

Op must not cause an exceptionthat may terminate the programexecution when br is taken

»

Op is executed more often thanit is supposed to (speculated

)

»

Page fault or cache miss are ok

Y

Insert control dep when eitherrestriction is violated

… if (x > 0)

y = z / x

1: branch x <= 0

2: y = z / x

control flow graph

• 9 -

Add control dependences to SB

Superblock

Assumed liveout sets

1: r1 = r2 + r32: r4 = load(r1)3: p1 = cmpp(r2 == 0)4: branch p1 Exit15: store (r4, -1)6: r2 = r2 – 47: r5 = load(r2)8: p2 = cmpp(r5 > 9)9: branch p2 Exit

{r1}

{r2}

All ops have cdep to op 9!

{r5}

Notes: All branches are control dependent on one another. If no compensation, all ops dependent on last branch

• 10 -

Class problem (1)

1: r1 = r7 + 42: branch p1 Exit13: store (r1, -1)4: branch p2 Exit25: r2 = load(r7)6: r3 = r2 – 47: branch p3 Exit38: r4 = r3 / r

{r4} {r1} {r2}

{r4, r8}

Draw the dependence graph

• 12 -

Restricted speculation model

Y

Most processors have 2classes of opcodes

»

Potentially exception causing

y

load, store, integer divide,floating-point

»

Never excepting

y

Integer add, multiply, etc.

y

Overflow is detected, butdoes not terminate programexecution

Y

Restricted model

»

R2 only applies to potentiallyexception causing operations

»

Can freely speculate allnever exception ops (stilllimited by R1 however)

We assumedrestrictedspeculationwhen thisgraph wasdrawn.This is whythere is nocdep between 4

Æ

6 and

Æ

• 13 -

General speculation model

Y

2 types of exceptions

»

Program terminating (traps)

y

Div by 0, illegal address

»

Fixable (normal and handledat run time)

y

Page fault, TLB miss

Y

General speculation

»

Processor provides non-trapping versions of alloperations (div, load, etc)

»

Return some bogus value (0)when error occurs

»

R2 is completely ignored,only R1 limits speculation

»

Speculative ops convertedinto non-trapping version

»

Fixable exceptions handledas usual for non-trapping ops

Removeedge from4 to 7

• 15 -

Class problem (2)

1: r1 = r7 + 42: branch p1 Exit13: store (r1, -1)4: branch p2 Exit25: r2 = load(r7)6: r3 = r2 – 47: branch p3 Exit38: r4 = r3 / r

{r4} {r1} {r2}

{r4, r8}

1. Starting with the graph assuming restricted speculation, what edges can be removed if general speculation support is provided? 2. With more renaming, what dependences could be removed?

• 16 -

Sentinel speculation model

Y

Ignoring all speculative exceptionsis painful

»

Debugging issue (is a programever fully correct?)

Y

Also, handling of all fixableexceptions for speculative ops canbe slow

»

Extra page faults

Y

Sentinel speculation

»

Mark speculative ops (opcode bit)

»

Exceptions for speculative opsare noted, but not handedimmediately (return garbagevalue)

»

Check for exception conditions inthe “home block” of speculativepotentially excepting ops

1: branch x == 0

2: y = *x 3: z = y + 4

4: *w = z

2’: y = *x 3’: z = y + 4

1: branch x == 0^ check exception

4: *w = z

• 18 -

Delaying speculative exceptions (2)

Y

Check for exceptions

»

Test NAT bit of appropriateregister (last register independence chain) in home block

»

Explicit checks

y

Insert new operation to checkNAT

»

Implicit checks

y

Non-speculative use of registerautomatically serves as NATcheck

Y

Regenerate exception

»

Figure out the exact cause

»

Handle if possible

»

Check with NAT conditionbranches to “recovery code”

»

Compiler generates the recoverycode specific to each check

1: branch x == 0

2: y = *x 3: z = y + 4

4: *w = z

2’: y = *x 3’: z = y + 4

1: branch x == 0

check NAT(z)

4: *w = z

• 19 -

Delaying speculative exceptions (3)

2’: y = *x 3’: z = y + 4

1: branch x == 0 branch NAT(z) fixup

4: *w = z

2’’: y = *x 3’’: z = y + 4

jump done

fixup:

done:

Recovery code

In recovery code, the exception condition will be regenerated as the excepting op is re-executed with the same inputs If the exception can be handled, it is, all dependent ops are re-executed, and execution is returned to point after the check If the exception is a program error, execution is terminated in the recovery code

Recovery code consists of chain of operations starting with a potentially excepting speculative op up to its corresponding check