Control Flow Graph, Dominators - Control Flow 1 | EECS 483, Exams of Electrical and Electronics Engineering

Download Control Flow Graph, Dominators - Control Flow 1 | EECS 483 and more Exams Electrical and Electronics Engineering in PDF only on Docsity!

Control Flow 1: Control Flow Graph, Dominators

EECS 483 – Lecture 19 University of Michigan Monday, November 13, 2006

• 1 -

Exam 1 Results

15014013012011010090 80 70 60 50 40 30 20 10 0

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

Exam score Average: 119

Stdev: 17.

High: 147

• 3 -

From Last Time: Structure Alignment

Each field is layed out in the order it isdeclared using Golden Rule for aligning

Identify largest field

» Starting address of overall struct is aligned

based on the largest field

» Size of overall struct is a multiple of the largest

field

» Reason for this is so can have an array of

structs

• 4 -

From Last Time: Class Problem

short a[100];

size = 200, halfword aligned, maps to addrs 1000 - 1199

char b;

size = 1, byte aligned, maps to addr 1200

int c;

size = 4, word aligned, maps to addrs 1204-

double d;

size = 8, double aligned, maps to addrs, 1208-

short e;

size = 2, halfword aligned, maps to addrs, 1216-

struct {

max field = int, thus must be word aligned, start at addr 1220

char f;

size = 1, byte aligned, maps to addr, 1220

int g[1];

size = 4, word aligned, maps to addrs, 1224-

char h[2];

size = 2, byte aligned, maps to addrs 1228-

} i;

overall size of struct must be multiple of 4, thus pad out to

How many bytes of memory does the following sequence of C declarations require (int = 4 bytes)? Assume we start at a word aligned address, say 1000

Total size = 232 bytes

• 6 -

Compiler Backend Introduction

Work at the assembly level

2 major concerns

» How to make the code go faster

y Machine independent opti y Machine dependent opti y Analyze program, understand its behavior, thentransform it to a more efficient form

» Map program onto real hardware

y Deal with limitations of processor y Virtual to physical binding (resource binding)

» Code size is 3

rd

concern, but not that important

• 7 -

Compiler Backend Structure

Control flow analysis Control flow optimization

Dataflow analysis Dataflow optimization Instruction Scheduling Instruction Selection^ Register Allocation

Machine Code Emission/Opti

Improve code quality (machine independent opti Virtual to physical mapping and machine dependent opti

Branching structure^ Computation^ instructions^ Bind instrs to^ physical realizations^ Bind instrs to^ physical resources^ Bind virtual regs^ to physical regs

• 9 -

Control Flow

™

Control transfer = branch (taken or fall-through)

™

Control flow^ » Branching behavior of an application^ » What sequences of instructions can be executed

™

Execution

Æ

Dynamic control flow

» Direction of a particular instance of a branch » Predict, speculate, squash, etc.

™

Compiler

Æ

Static control flow

» Not executing the program » Input not known, so what could happen, worst case

• 10 -

Basic Block (BB)

™

Group operations into units with equivalentexecution conditions

™

Defn: Basic block

• a sequence of consecutive

operations in which flow of control enters at thebeginning and leaves at the end without halt orpossibility of branching except at the end^ » Straight-line sequence of instructions^ » If one operation is executed in a BB, they all are

™

Finding BB’s^ » The first operation starts a BB^ » Any operation that is the target of a branch starts a BB^ » Any operation that immediately follows a branch

starts a BB

• 12 -

Control Flow Graph (CFG)

™

Defn Control Flow Graph

Directed graph, G = (V,E)where each vertex V is a basicblock and there is an edge E,v1 (BB1)

Æ

v2 (BB2) if BB

can immediately follow BB1in some execution sequence^ »

A BB has an edge to all blocksit can branch to »^

Standard representation used bymany compilers »^

Often have 2 pseudo vertices^ y

entry node y^

exit node

BB

BB

BB

BB

BB

BB

Entry^ BB7^ Exit

• 13 -

CFG Example x = z – 2; y = 2 * z; if (c) {

x = x + 1; y = y + 1; } else {

x = x – 1; y = y – 1; } z = x + y

x = z – 2;y = 2 * z;if (c) B2 else B

x = x + 1;y = y + 1;goto B

z = z + y

x = x – 1;y = y – 1;

then(fallthrough)

else(taken)

B

B

B

B

• 15 -

Weighted CFG

™

Profiling

• Run the application

on 1 or more sample inputs,record some behavior^ »

Control flow profiling**^ y

edge profile y^

block profile

»^

Path profiling

™

Annotate control flow profileonto a CFG

Æ

weighted CFG

™

Optimize more effectively withprofile info!!^ »

Optimize for the common case »^

Make educated guess

BB

BB

BB

BB

BB

BB

Entry^ BB7^ Exit

20

10

10

10

10

15

5

15

5 20

• 16 -

Control Flow Analysis

™

Determining properties of the program branchstructure^ » Static properties

Æ

Not executing the code

» Properties that exist regardless of the run-time branch

directions » Use CFG » Optimize efficiency of control flow structure

™

Determine instruction execution properties^ » Global optimization of computation operations^ » Discuss this later

• 18 -

Dominator Examples

BB

BB

BB

BB

BB

BB

Entry^ BB7^ Exit

BB2 BB

BB

BB

Entry

BB1 BB6^ Exit

• 19 -

Dominator Analysis

™

Compute dom(BBi) = set of BBsthat dominate BBi ™

Initialization^ »

Dom(entry) = entry »^

Dom(everything else) = all nodes

™

Iterative computation^ »

while change, do^ y

change = false y^

for each BB (except the entry BB)^ ‹

tmp(BB) = BB + {intersect of Domof all predecessor BB’s} ‹ if (tmp(BB) != dom(BB))

È

dom(BB) = tmp(BB) È

change = true

BB

BB

BB

BB

BB

BB

Entry^ BB7^ Exit