Advanced Compilers: University of Michigan EECS 583 Course Overview - Prof. Scott Mahlke, Study notes of Electrical and Electronics Engineering

Download Advanced Compilers: University of Michigan EECS 583 Course Overview - Prof. Scott Mahlke and more Study notes Electrical and Electronics Engineering in PDF only on Docsity!

EECS 583 – Advanced Compilers

Winter 2003, University of Michigan Scott Mahlke (mall-key) Lecture 1 January 6, 2003

Class Overview

Y

This class is NOT about:^ »

Programming languages (despite what the grad handbook sez) »^

Parsing, syntax checking »^

Handling advanced language features – virtual functions, … »^

Frontend transformations – array dependence analysis, … »^

Debugging »^

Simulation

Y

Compiler backend^ »

Mapping applications to processor hardware »^

Retargetability – work for multiple platforms (not hard coded) »^

Work at the assembly-code level^ y

Processor independent -> Machine code

»^

Speed/Efficiency^ y

How to make the application run fast y Use less memory (text, data)

Textbook and Other Classroom Material

Y

No required text – Lecture notes, papers

Y

Recommended reference texts^ »

“Compilers: Principles, Techniques, Tools”, by Aho, Sethi,Ullman (aka red dragon book) »^

“Building an Optimizing Compiler”, by Morgan

Y

Other useful material^ »

Trimaran webpage: http://www.trimaran.org »^

UIUC Impact webpage: http://www.crhc.uiuc.edu/Impact

Y

Course webpage + course newsgroup^ »

Will be set up later this week »^

Lecture notes »^

Newsgroup – forum for helping each other, I will try to checkregularly

What the Class Will be Like

Y

Class meeting time – 3:30 – 6:00, MW^ »

2.5 hrs is WAY too much »^

We’ll go about 2 hours, with a 10 minute break at 4:30pm

Y

First half: 400-level class^ »

Text book material – basic of compiler backend techniques »^

I lecture, you guys do homeworks »^

Midterm exam

Y

Second half: true grad class^ »

Research papers »^

Discussion »^

Presentations by students – You guys are going to teach

Course Grading

Y

Yes, everyone will get a grade^ »

Distribution of grades, scale, etc - ??? »^

Most (hopefully all) will get A’s and B’s »^

Slackers will be obvious and will suffer »^

If you wanted a blow off class – consider dropping

Y

Components^ »

Midterm exam – 30% »^

Project – 35% »^

Homeworks – 20% »^

Class participation and involvement – 15%^ y

Paper presentation – 7.5% y General – 7.5%

Homeworks

Y

Around 5 of these^ »

Small/modest programming assignments »^

Design and implement something we discussed in class

Y

Goals^ »

Learn the important concepts »^

Practice for the midterm »^

Learn the compiler infrastructure so you can do the project

Y

Grading^ »

2/1/0 (good, so-so, didn’t try very hard)

Y

Working together is ok^ »

Make sure you understand things or it will come back to bite you »^

For now, everyone must turn in their own assignment, maychange this later in the semester

Class Participation

Y

Interaction and discussion is essential in a graduate class^ »

Be here »^

Don’t just stare at the wall »^

Be prepared to discuss the material »^

Have something useful to contribute

Y

Opportunities for participation^ »

Research paper presentation^ y

Put some effort into this – clear/illustrative presentation

»^

Research paper discussions – thoughts, comments, etc »^

Saying what you think in the special interest group meetings »^

Solving class problems »^

Feedback to me about the class

Special Interest Groups

Y

Divide up the class into 4 focus groups^ »

Each group will meet every other week for 1 hr (time/place TBD) »^

Identify research papers, discuss papers and project ideas

Y

4 groups – equal number of people in each group^ »

Branches/predicates »^

Instruction-level parallelism »^

Memory hierarchy »^

Power

Y

SIGs from last time^ »

Control flow analysis / optimization »^

Dataflow analysis / optimization »^

Code generation, scheduling, register allocation »^

Memory hierarchy optimization

Contact Info

Y

Office: 2223 EECS

Y

Email: [email protected]

Y

Office hours^ »

Mon, Wed: before and after class »^

Y

Visiting office hrs^ »

No GSI for this class »^

You will have to be independent in this class^ y

RTFM y Come to me when you are really stuck or confused y Helping each other is encouraged

Awakening Some Interest in Compilers

Y

Traditional strength at Michigan - Architecture^ »

Superscalar processors, do everything in hardware »^

Emphasis on Pentium class architectures

Y

Little on compilers^ »

Hardware people have to understand compilers^ y

No attention to compilers -> bad processor design

»^

483 material is not what real compiler people focus on^ y

Parsing, syntax checking, etc – Standard, mature field

»^

This class material is where all the action is at^ y

How to make code run fast (approach hand coding) y How to reduce power y How to reduce code size y How to make use of unusual architectural features y How to design better processors y How to design customized processors

• 15 -

VLIW/EPIC Philosphy

Y

Compiler creates complete plan of run-time execution^ »

At what time and using what resource »^

POE communicated to hardware via the instruction set »^

Processor obediently follows POE »^

No dynamic scheduling, out of order execution (these second guess thecompilers plan)

Y

Compiler allowed to play the statistics^ »

Many types of info only available at run-time (branch directions,locations accessed via pointers) »^

Traditionally compilers behave conservatively

Æ

handle worst case

possibility »^

Allow the compiler to gamble when it believes the odds are in its favor^ y

Profiling

Y

Expose microarchitecture to the compiler^ »

memory system, branch execution

• 16 -

Defining Feature I - MultiOp

Y

Superscalar»

Operations are sequential »^

Hardware figures out resource assignment, time of execution

Y

MultiOp instruction»

Set of independent operations that are to be issuedsimultaneously (no sequential notion within a MultiOp) »^

1 instruction issued every cycle – provides notion of time »^

Resource assignment indicated by position in MultiOp »^

POE communicated to hardware via MultiOps add

sub

load

load

store

mpy

shift

branch

• 18 -

UAL vs NUAL example^ Instruction^1234567891011

Operation r1 = load(r2) r1 = load(r3) r4 = mpy(r1, r5) r4 = add(r1, r6) r7 = mpy(r4, r9) r7 = add(r7, r8)

Phase1 Operation v1 = load(r2) v2 = load(r3) v3 = mpy(r1, r5) v4 = add(r1, r6) v5 = mpy(r4, r9) v6 = add(r7, r8)

Phase2 Operation r1 = v1 r1 = v2 r4 = v4 r4 = v3 r7 = v6 r7 = v

traditional

NUAL

Assume load = 4 cycles, add = 1, mpy = 3

Other Architectural Features of VLIW/EPIC

Y

Add features into the architecture to support VLIW/EPICphilosphy^ »

Create more efficient POEs »^

Expose the microarchitecture »^

Play the statistics

Y

Register structure

Y

Branch architecture

Y

Data/Control speculation

Y

Memory hierarchy management

Y

Predicated execution