Similar presentations

2
University of Maryland Why do we need better code generation? Dyninst has evolved through its releases –Originally designed with Paradyn in mind Frequent changes to instrumentation Current code generation requirements –Not have adverse effects on pre-existing program –Tuned to handle future changes to instrumentation Certain optimizations currently in compilers can be used for Dyninst –Dataflow analysis –Register allocation Because it is a dynamic environment certain modifications need to be performed

3
University of Maryland Methods to Improve Code Generation Decrease Register Spills –No Function Call Save only registers generated by a mini-tramp –Function Call Do Analysis to see which registers need saving Merge Base Tramp & Mini-Tramp –Need to create flag after first instrumentation –Only one mini-tramp created per site Dataflow analysis for Dead Registers –Useful for arbitrary instrumentation points

5
University of Maryland New Register Implementation Base Tramp Generation –Only registers explicitly used within base tramp are saved –Series of place holder noops are generated for those registers not saved –Jump created at last save/restore to end of noop group Mini Tramp Generation –Keeps track of all volatile registers used After Mini Tramp Generation –Noops are replaced within base tramp with save(s)/restore(s) –Jump is updated

10
University of Maryland Dealing with Function Calls Linear scan on instructions for function that is called from mini-tramp –Record all modified registers within function –Make recursive calls when needed At certain cut-off point assume all registers were clobbered

11
University of Maryland Merging Base & Mini Tramp Original Design Decisions for Dyninst made to use Paradyn’s instrumentation usage pattern –Large amount of instrumentation changed frequently Can generate better code for various reasons –Eliminates noops for registers in base tramp –Eliminates link register modifications and branches –Makes assembly more stream-lined And readable … if you’re in to that kind of thing One instrumentation point installed … that’s it –Functionality somewhat limited Tradeoff of speed for ease of further instrumentation –Delete then reinsert (Replace)

12
University of Maryland How will it work? Create flag for BPatch class in API –Once flag is set merging is set –When flag gets reset system reverts to old style –void setMergeTramp(bool x) Similar to recursion flag currently in Dyninst No effect on current Dyninst use –Default flag set to no merging Most users will probably leave it at one setting based on instrumentation needs

13
University of Maryland Mini-tramp operation comparison No Merging –Insert Same as before, unlimited per instrumentation site –Delete Deletes instance of mini-tramp Merging –Insert Only one mini-tramp allowed to be inserted, instrumentation point locked after first mini tramp generated –Delete Deletes instance of mini-tramp and base tramp –Replace Delete, then Insert new Possible to save AST information at the old mini tramp to be used for new instrumentation

14
University of Maryland Dataflow analysis for Dead Registers Register use after instrumentation –Overwritten before accessed We are free to use them in tramp without having to spill them –Not overwritten Spill to stay on cautious side Do analysis before tramp generation –Dead registers have highest priority –Currently same registers used regardless

16
University of Maryland Other Speed-ups for Dyninst Partial Parsing of functions –Grab symbol table and create function objects –Delay analysis until function is actually accessed –User can’t see non-symbol-table functions Therefore, We don’t have to worry about them

17
University of Maryland Status Completed and in New Release (POWER) –New Register Spilling for Basic Snippets Registers Spilled for Function Calls from a Mini Tramp –Partial Parsing (All platforms) Currently Being Implemented (POWER) –Linear Code Scan for function calls –Base Tramp, Mini Tramp Merging –Data Flow Analysis for Dead Registers Will eventually be on all platforms