D A C

U

CP

Speculative Alias Analysisfor Executable Code

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

MotivationMotivation

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 codeAlias 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 outlineTalk outline

Motivation

Speculative alias analysis

Evaluation

Summary

D A C

U

CP

Speculative alias analysisSpeculative 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

SafenessSafeness

PrecisionPrecision Resourceusage (cost)

Resourceusage (cost)

AliasAnalysis

AliasAnalysis

D A C

U

CP

Propagating memory regionsPropagating 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 analysisRegion-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 pathsPropagating 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 analysisProfile-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 algorithmA 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 outlineTalk outline

Motivation

Speculative alias analysis

Evaluation

Summary

D A C

U

CP

MethodologyMethodology

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 effectivenessEvaluating 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 precisionStatic precision

0%

10%

20%

30%

40%

50%

60%

70%

80%

90%

100%

go

m88ksim gcc

compress liijp

egperl

vortex

Average

Dis

am

big

ua

tio

n q

ue

rie

s (

%) Unknown

PG/Reg'

PG/Reg

PG/Res

Region

Residue

Inspect

D A C

U

CP

Misspeculation rateMisspeculation rate

0

0,5

1

1,5

2

2,5

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

Analysis method

Mis

sp

ec

ula

ted

qu

eri

es

(%

)

D A C

U

CP

Talk outlineTalk outline

Motivation

Speculative alias analysis

Evaluation

Summary

D A C

U

CP

SummarySummary

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