Speculative Alias Analysis for Executable Code Manel Fernndez

Speculative Alias Analysis for Executable Code Manel Fernández and Roger Espasa Computer Architecture Department Universitat Politècnica de Catalunya Barcelona, Spain {mfernand, roger}@ac. upc. es U P C D A C

Motivation n Alias analysis l Provides information for memory disambiguation m l Key issue in today’s optimizing compilers Formulated as a dataflow analysis m m In terms of source language constructs Trade-off between cost and precision n Executable code optimizers l New optimization opportunities appear m l Limited usefulness of “traditional” analyses m m U P C Whole program view, etc. High level information is lost Object code is larger than corresponding source code n Memory disambiguation is one of the weak points of object code modification D A C

Alias analysis on executable code n Existing techniques l Instruction inspection m l Register use-def chains Residue-based alias analysis m [Debray et al. POPL ‘ 98] m Arithmetic computations mod-k – Small displacements from a base register m “Fine grain” disambiguation n Problems of existing alias analysis l Low precision m l Strong resource-usage constraints m U P C m D A C Conservative assumptions Widening: less precision joining different definitions Context-insensitive formulation

Talk outline n Motivation n Speculative alias analysis n Evaluation n Summary U P C D A C

Speculative alias analysis n Existing analysis are conservative l Trade off between cost and precision Safeness n A new variable: safeness l Analysis becomes speculative m m Increases precision at low cost Analysis is not always correct Alias Analysis n Our proposals l Two may-alias approaches m m l m D A C Resource usage (cost) Well-suited for speculative optimizations m U P C Region-based alias analysis Profile-guided alias analysis Precision Speculative reordering based on check-and-recovery schemes E. g. : reordering memory operations

Propagating memory regions n Observations l Conservative propagation of descriptors m l E. g. : operating different definitions Loads produce conservative descriptors m Nothing is known about the loaded value n Key ideas l Propagation without losing precision m l Propagating “very basic” information “Guessing” possible memory regions m Memory regions “are disjoint” – Global – Stack – Heap U P C D A C I 2 I 1 I 2 . . . load add store load. . . (sp), r 1 gp, r 1 r 0, (r 1) (sp), r 0

Region-based alias analysis n Interprocedural low-level scheme l Well-suited for executable code n Computation of memory regions l For each register r defines S m S: set of regions {Global, Stack, Heap} I 2 m T = Æ, ^ = {G, S, H} l l Dataflow propagation Speculative approach m l I 1 I 2 Assumptions are not always correct . . . load add store load. . . (sp), r 1 gp, r 1 r 0, (r 1) (sp), r 0 “Coarse-grain” disambiguation m Can be applied coupled to a residue-based scheme n Aggressive region-based analysis l U P C Loaded values are hardly ever aliased with other pointers m D A C l E. g. : linked lists Set load destination descriptors to T instead of ^

Propagating likely paths n Observations l Widening operation is conservative m E. g. : l several definitions reaching a use Context-insensitive analysis m Context-sensitive is not feasible . . . add n Key ideas l Propagation without loosing precision m Reducing l are not significant at run time m Ignore “cold” paths U P C D A C . . . add gp, 0, r 1 the number of paths “Cold” references are not important m Conflicts Hot path sp, 0, r 1 I 2 store r 0, (r 1) load (sp), r 0. . .

Profile-guided alias analysis n Interprocedural general scheme l Needs profile information n Only likely executed paths are considered l Applied on top of any dataflow analysis m Redefine l Speculative approach m “Cold” l U P C D A C join operation paths are ignored “Likely-path” disambiguation

A combined algorithm n Alias analysis scheme n Disambiguation scheme l Phase 1 m l Phase 2 m m l D A C Residue-based Region-based Phase 3 m U P C Use-def chains Profile-guided Phase 2 Input: I 1, I 2 Output: {dependent, independent, likely independent, unknown} Method: if ud-chains(I 1, I 2) ≠ unknown return ud-chains(I 1, I 2); if aliasing(I 1, I 2, safe) ≠ unknown return aliasing(I 1, I 2, safe); if aliasing(I 1, I 2, unsafe) ≠ unknown return likely independent; else return unknown; End Method

Talk outline n Motivation n Speculative alias analysis n Evaluation n Summary U P C D A C

Methodology n Benchmark suite l SPECint 95 m Compiled on an Alpha. Server with full optimizations m Intrumented using Pixie to get profiling information n Experimental framework l l Alto executable optimizer Simple. Scalar safe simulator n Evaluation l l U P C D A C Static precision Misspeculation rate

Evaluating effectiveness n Disambiguation query l l “Question” made to the memory disambiguator Relationship between two memory references m Dependent, independent, likely independent m Unknown n Set of disambiguation queries l l Pair of references that belong to the same function Building the set m Consider every load/store in a hot path (2 nd item) m Consider every load/store in previous paths (1 st item) l U P C D A C Typical behavior of compiler optimizations

Static precision U P C D A C

Misspeculation rate U P C D A C

Talk outline n Motivation n Speculative alias analysis n Evaluation n Summary U P C D A C

Summary n Memory disambiguation is one of the weak points of object code modification n Speculative alias analysis l Compromise among cost, precision and safeness m m l Region-based alias analysis Profile-guided alias analysis Well-suited for executable code n Conclusions l l Precision increases from 16% up to 83% in average Misspeculation rate around 1% m l U P C D A C In front of 2% using an “always speculate” scheme To be used for reordering memory operations with high recovery cost