d a c u c p speculative alias analysis for executable code manel fernández and roger espasa...

D A C

U

CP

Speculative Alias Analysisfor Executable Code

Manel Fernández and Roger EspasaComputer Architecture Department

Universitat Politècnica de Catalunya

Barcelona, Spain

{mfernand,roger}@ac.upc.es

D A C

U

CP

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

D A C

U

CP

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

D A C

U

CP

Talk outline Motivation Speculative alias analysis Evaluation Summary

D A C

U

CP

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

Safeness

Precision Resourceusage (cost)

AliasAnalysis

D A C

U

CP

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

...I2 load (sp),r1I2 add gp,r1,r1I1 store r0,(r1)I2 load (sp),r0 ...

D A C

U

CP

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

...I2 load (sp),r1I2 add gp,r1,r1I1 store r0,(r1)I2 load (sp),r0 ...

D A C

U

CP

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

I1 store r0,(r1)I2 load (sp),r0 ...

...add sp,0,r1

...add gp,0,r1

Hotpath

D A C

U

CP

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

npr

pr

mpr

pr

npr

pr

,1,,1,,1,PG

,,,,,,,

D A C

U

CP

A combined algorithm Alias analysis scheme

Phase 1 Use-def chains

Phase 2 Residue-based Region-based

Phase 3 Profile-guided Phase 2

Disambiguation scheme

Input: I1,I2

Output: {dependent, independent, likely independent, unknown}Method: if ud-chains(I1,I2) ≠ unknown return ud-chains(I1,I2); if aliasing(I1,I2,safe) ≠ unknown return aliasing(I1,I2,safe); if aliasing(I1,I2,unsafe) ≠ unknown return likely independent; else return unknown;End Method

D A C

U

CP

Talk outline Motivation Speculative alias analysis Evaluation Summary

D A C

U

CP

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

D A C

U

CP

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

D A C

U

CP

Static precision

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

go

m88ksim gcc

compress liijpeg perl

vortexAverage

Dis

ambi

guat

ion

quer

ies

(%) Unknown

PG/Reg'PG/RegPG/ResRegionResidueInspect

D A C

U

CP

Misspeculation rate

0

0,5

1

1,5

2

2,5

Region PG/Res PG/Reg PG/Reg' Always

Analysis method

Mis

spec

ulat

ed q

uerie

s (%

)

D A C

U

CP

Talk outline Motivation Speculative alias analysis Evaluation Summary

D A C

U

CP

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