1. Building on Phoenix Michael D. Smith Harvard University © Copyright by Michael D. Smith 2005 All rights reserved.

2. 2 Wonderful Opportunity Compilation creeping into everything virtual execution environments security systems instrumentation tools Phoenix is a substrate that could unify these efforts allow me to focus on research and not infrastructure building

3. 3 The Next 10 Minutes How I’m moving my research to Phoenix static compilation dynamic optimization (security and privacy) Why I’m hiding Phoenix as the substrate simplify the system for teaching minimize impact of future changes make extensions indistinguishable from that which is directly supported

4. 4 Successful Transition A generalized algorithm for graph-coloring register allocation [ PLDI’04 ] we’ve made Chaitin’s approach simple to apply to real machines Used Phoenix’s extensibility features wrote a Phx.PlugIn replaces current register allocation phase didn’t extend Phx.IR, but did define new data structures built from existing classes

5. 5 Research Work In-Progress New efforts in dynamic optimization Driving observation: runtime opt. differs from compile-time opt. opt. effort should pay off contextual info is costly Current research thrusts: phase ordering and combining optimizations [ PLDI’05 poster ] region selection [ in submission ]

6. 6 Varia: Inference-driven Opt. Kelly Heffner and Kevin Redwine Tool for exploring opt. space represent opts. as inference rules explore space using a rules engine Easy to define new opts. combine opts. Many challenges x is dead after i i does not read x x is dead before i … x is dead after i … x is dead before i … i does not read x … … x is dead after i … i does not read x … facts rules facts match rule preconditions rule fires, producing a new fact

7. 7 Improving Region Selection in Dynamic Optimization Systems David Hiniker and Kim Hazelwood A good region-selection algorithm limits profiling and optimization overheads brings together frequently executing code Two choices today: whole methods (for JIT compilation) traces (for everything else) Our current goal: beat Dynamo’s Next-Executing Tail (NET)

8. 8 Our Proposed Techniques Last-Executed Iteration (LEI) select more traces that span loops avoid duplicating nested loops Trace Combination allow regions to include multiple overlapping paths reduces problems of separation and duplication in LEI & NET Open Question: better for optimization?

9. 9 OPI/Phoenix Port (and update) of OPI/SUIF OPI: Optimization Programming Interface isolates opt. passes from substrate produces clean, textbook-like code puts core system features and later extensions on equal footing Result is a system that is better for teaching better for long-term research

10. 10 History OPI/SUIF grew out of concurrent development of SUIF and Machine SUIF SUIF was substrate for Machine SUIF Headaches: we hated it when they (inevitably) changed some aspect of SUIF we didn’t “own” the source to SUIF and wanted different capabilities in the core

11. 11 History Repeats OPI/SUIF grew out of concurrent development of SUIF and Machine SUIF and our users’ extensions Machine SUIF was substrate for x-SUIF Headaches: our users hated it when we (inevitably) changed some aspect of Machine SUIF our users didn’t “own” the source to Machine SUIF and wanted different capabilities in the core

12. 12 Applicability to Phoenix The research community will use (not own) Phoenix The Phoenix API is still evolving Andy Ayers recently spoke for 135 min. and only gave a “superficial overview”on the Phoenix IR, symbols, and types Phoenix has been built to be extensible can decorate IR objects and grab control but no guidelines on how to produce compatible extensions

13. 13 OPI/SUIF Code Example // Spill i-th source operand of instruction at h in // CFG node n, inserting a register-load instruction // just before h. void spill_src(InstrHandle h, int i, CfgNode* node) { Instr* instr = *h; Opnd opnd = get_src(instr, i); TypeId type = get_type(opnd); // replace operand by virtual register Opnd vr = opnd_reg(type); set_src(instr, i, vr); // load spilled value before original instruction Instr* ld = new_instr_alm(vr, load_opcode(t), opnd); insert_before(node, h, ld); } Key: OPI IR types in red. OPI functions in blue.

14. 14 OPI/Phoenix Code Example // Spill i-th source operand of instruction at h in // CFG node n, inserting a register-load instruction // just before h. public void SpillSrc(InstrHandle h, int i, CfgNode node) { Instr instr = h.Value; Opnd opnd = GetSrc(instr, i); Type type = GetType(opnd); // replace operand by virtual register Opnd vr = NewOpndReg(type); SetSrc(instr, i, vr); // load spilled value before original instruction Instr ld = NewInstrAlm(vr, LoadOpcode(type), opnd); InsertBefore(node, h, ld); } Key: OPI IR types in red. OPI functions in blue.

15. 15 Updates and Differences C# instead of C++ OO style, instead of C style stylistically better iterators etc. Machine SUIF included the development of a new LIR Phoenix provides us with a LIR eliminate IR stuff that crept into definition of OPI/SUIF

16. 16 Conclusion We’re looking to use Phoenix in many different research projects common thread: the need to generate, analyze, or optimize code We’re also looking to make Phoenix an outstanding platform for pedagogy research that builds on the work of others