Control Flow Analysis and Optimization in Compiler Backend: Dominators and Basic Blocks, Study notes of Electrical and Electronics Engineering

Download Control Flow Analysis and Optimization in Compiler Backend: Dominators and Basic Blocks and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

Control Flow Analysis/Opti I Control Flow Graph, Dominators

EECS 483 – Lecture 16 University of Michigan Monday, November 8, 2004

• 1 -

Memory Alignment – From Last Time^ Y^ Cannot arbitrarily pack variables intomemory

Æ^

Need to worry about alignment

Y^ Golden rule – Address of a variable isaligned based on the size of the variable^ » Char is byte aligned (any addr is fine)^ » Short is halfword aligned (LSB of addr must

be 0) » Int is word aligned (2 LSBs of addr must be 0) » This rule is for C/C++, other languages mayhave a slightly different rules

• 3 -

Class Problem – From Last Time 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 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 Total size = 232 bytes

• 4 -

Compiler Backend Introduction^ Y^ Work at the assembly level^ Y^ 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

• 6 -

Compiler Backend IR^ Y^ Low Level IR (intermediate representation)

» Machine independent assembly code^ y^

Instruction set for abstract machine

» r1 = r2 + r3 or equivalently add r1, r2, r3^ y^

Opcode y Operands^ X^ Virtual registers – infinite number of these^ X^ Special registers – stack pointer, pc, etc.^ X^ Literals – compile-time constants (no limit onsize of these)^ X^ Symbolic names – start of array, branch targets

• 7 -

Backend IR != Project 3 Output^ Y^ Unfortunately, you are not generating thelow IR for Project 3

» Opcode repertoire is the same (PISA) Y For Project 3 » You are generating machine code directly!^ y^

Essentially skipping Low IR

» You generate physical registers (not virtual) » Must save/restore registers » Build complete stack frame » Literals matter

• 9 -

Basic Block (BB)^ Y^ Group operations into units with equivalentexecution conditions^ Y^ 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 Y 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 branchstarts a BB

• 10 -

Class Problem^ Identify the BBs in this^ code sequence:

L1: r7 = load(r8) L2: r1 = r2 + r3 L3: beq r1, 0, L10 L4: r4 = r5 * r6 L5: r1 = r1 + 1 L6: beq r1 100 L2 L7: beq r2 100 L10 L8: r5 = r9 + 1 L9: r7 = r7 & 3 L10: r9 = load (r3) L11: store(r9, r1)

Remember: 2 main rules: * Rule 1: Each branch ends a basic block * Rule 2: Each branch target starts a basic block

• 12 -

CFG Example

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

x = z – 2; y = 2 * z; if (c) {^ x = x + 1;^ y = y + 1; } else {^ x = x – 1;^ y = y – 1; } z = x + y

then(fallthrough)

else(taken)

B^

B

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

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

B4^ z = z + y

• 13 -

Another CFG Example

L1: r7 = load(r8)L2: r1 = r2 + r3L3: beq r1, 0, L10L4: r4 = r5 * r6L5: r1 = r1 + 1L6: beq r1 100 L2L7: beq r2 100 L10L8: r5 = r9 + 1L9: r7 = r7 & 3L10: r9 = load (r3)L11: store(r9, r1) 1 2 3 4 5 6

• 15 -

Control Flow Analysis^ Y^ Determining properties of the program branchstructure

» Static properties

Æ^ Not executing the code

» Properties that exist regardless of the run-time branchdirections » Use CFG » Optimize efficiency of control flow structure Y Determine instruction execution properties » Global optimization of computation operations » Discuss this later

• 16 -

Dominator^ Y^ Defn: Dominator

• Given a CFG(V, E, Entry,

Exit), a node x dominates a node y, if every pathfrom the Entry block to y contains x Y 3 properties of dominators^ » Each BB dominates itself^ » If x dominates y, and y dominates z, then x dominates z^ » If x dominates z and y dominates z, then either xdominates y or y dominates x Y Intuition^ » Given some BB, which blocks are guaranteed to haveexecuted prior to executing the BB

• 18 -

Dominator Analysis^ Y^ Compute dom(BBi) = set of BBsthat dominate BBi^ Y^ Initialization

»^ Dom(entry) = entry »^ Dom(everything else) = all nodes Y Iterative computation »^ while change, do^ y^

change = false y for each BB (except the entry BB)^ X^ tmp(BB) = BB + {intersect of Domof all predecessor BB’s}^ X^ if (tmp(BB) != dom(BB))^ ±

dom(BB) = tmp(BB) ± change = true

Entry^ BB1 BB2^ BB

BB BB^

BB6 BB7 Exit

• 19 -

Immediate Dominator^ Y^ Defn: Immediate^ dominator

(idom)– Each

node n has a uniqueimmediate dominator mthat is the last dominatorof n on any path from theinitial node to n^ » Closest node thatdominates

Entry^ BB1 BB2^ BB

BB BB^

BB6 BB7 Exit