Speculative Alias Analysis for Executable Code

1. Speculative Alias Analysisfor Executable Code Manel Fernández and Roger Espasa Computer Architecture Department Universitat Politècnica de Catalunya Barcelona, Spain {mfernand,roger}@ac.upc.es

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

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

4. Talk outline • Motivation • Speculative alias analysis • Evaluation • Summary

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

6. ... I2 load (sp),r1 I2 add gp,r1,r1 I1 store r0,(r1) I2 load (sp),r0 ... Propagating memory regions • Observations • Conservative propagation of descriptors • E.g.: operating different definitions • Loads produce conservative descriptors • Nothing is known about the loaded value • Key ideas • Propagation without losing precision • Propagating “very basic” information • “Guessing” possible memory regions • Memory regions “are disjoint” • Global • Stack • Heap

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

8. ... add sp,0,r1 Hot path ... add gp,0,r1 I1 store r0,(r1) I2 load (sp),r0 ... Propagating likely paths • Observations • Widening operation is conservative • E.g.: several definitions reaching a use • Context-insensitive analysis • Context-sensitive is not feasible • Key ideas • Propagation without loosing precision • Reducing the number of paths • “Cold” references are not important • Conflicts are not significant at run time • Ignore “cold” paths

9. Profile-guided alias analysis • Interprocedural general scheme • Needs profile information • Only likely executed paths are considered • Applied on top of any dataflow analysis • Redefine join operation • Speculative approach • “Cold” paths are ignored • “Likely-path” disambiguation

10. Alias analysis scheme Phase 1 Use-def chains Phase 2 Residue-based Region-based Phase 3 Profile-guided Phase 2 Disambiguation scheme A combined algorithm Input: I1,I2 Output: {dependent, independent, likely independent, unknown} Method: ifud-chains(I1,I2) ≠ unknown returnud-chains(I1,I2); ifaliasing(I1,I2,safe) ≠ unknown returnaliasing(I1,I2,safe); ifaliasing(I1,I2,unsafe) ≠ unknown returnlikely independent; else return unknown; End Method

11. Talk outline • Motivation • Speculative alias analysis • Evaluation • Summary

12. Methodology • Benchmark suite • SPECint95 • Compiled on an AlphaServer with full optimizations • Intrumented using Pixie to get profiling information • Experimental framework • Alto executable optimizer • SimpleScalar safe simulator • Evaluation • Static precision • Misspeculation rate

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

14. Static precision

15. Misspeculation rate

16. Talk outline • Motivation • Speculative alias analysis • Evaluation • Summary

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