P3DE: ProfileDirected Predicated Partial Dead Code Elimination - PowerPoint PPT Presentation

Loading...

PPT – P3DE: ProfileDirected Predicated Partial Dead Code Elimination PowerPoint presentation | free to view - id: 164fb1-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

P3DE: ProfileDirected Predicated Partial Dead Code Elimination

Description:

Coordinated Science Laboratory. University of Illinois at Urbana-Champaign ... Cannot sink out of loops unless the assignment is dead along the backedge ... – PowerPoint PPT presentation

Number of Views:98
Avg rating:3.0/5.0
Slides: 23
Provided by: shane97
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: P3DE: ProfileDirected Predicated Partial Dead Code Elimination


1
P3DEProfile-Directed Predicated Partial Dead
Code Elimination
  • Shane Ryoo, Sain-Zee Ueng, and Wen-mei W. Hwu
  • Coordinated Science Laboratory
  • University of Illinois at Urbana-Champaign
  • EPIC-5 Workshop, March 26th, 2006

2
Motivation
  • Even with classical optimizations, there still is
    a significant amount of executed code that is
    dead Butts ASPLOS 02
  • Our experience large amount of dead stores
  • Contemporary architectures generally can issue
    only one or two stores per cycle, increasing the
    length of a schedule in store-laden regions
  • Can we remove more of this dead code?
  • Push assignments off hot paths, towards uses

3
Partial Dead Code Elimination
  • Partial Dead Code Elimination (PDE) reduces
    execution of assignments whose results sometimes
    have no effect
  • Basic algorithm by Knoop et al. PLDI 94 sinks
    assignments to remove partially-dead code

assignment moves downward until it is blocked
(a) Before PDE
(b) After PDE
4
Previous Aggressive Dead Code Removal Techniques
  • Primary weakness of previous methods is their
    limitations with cyclic code regions
  • Gupta et al. PACT 97 present the only previous
    work on predicated PDE
  • Path profile-based method for cost-benefit
    analysis
  • Cannot sink out of loops unless the assignment is
    dead along the backedge
  • Bodik et al. PLDI 97 uses code restructuring
    to expose opportunities without introducing extra
    dynamic ops
  • Requires some method to control code growth
  • Cannot handle embedded control flow in a loop

5
Profile-Directed Predicated Partial Dead Code
Elimination
  • Use edge profile information to specialize
    program paths beyond basic PDE (essentially
    speculate)
  • Reduce the number of executions, based on profile
  • Use predication support to enable aggressive
    sinking motion on assignments
  • Uniform cost-benefit model for cyclic and acyclic
    code regions that accounts for predication
    overhead
  • Other optimizations to reduce/eliminate predicate
    usage and increase the applicability of the
    optimization Ryoo M.S. thesis 04

6
P3DE Example
computation of interest
side entry
new location
(a) Before P3DE
(b) After P3DE
7
P3DE Algorithm
  • Perform dataflow analyses to determine the
    possible range of motion for all assignments
  • Dead partially-dead
  • Partially delayable
  • For each assignment
  • Construct a motion graph representing this range
  • Compute a minimum cut of the motion graph, based
    on profile weights, to find the smallest number
    of executions
  • Insert new computations, delete old computations,
    and use predication as necessary to maintain
    correctness
  • Iterate until no profitable motions remain

8
Dead Assignment Dataflow
  • Is the assignment dead along ALL/ANY future
    paths?
  • If completely live (or blocked by aliasing
    operations), sinking the assignment cannot result
    in fewer executions
  • If completely dead, the assignment does not need
    to be executed (inserted)

dataflow direction
9
Partial Delay Dataflow
  • Can the assignment be sunk down any path with
    potential profit?
  • Filter out assignments which are live (not
    profitable to sink) when passing through blocks

dataflow direction
10
Motion Graph Construction
  • One graph per assignment
  • Every CFG edge is included in the motion graph
    which is
  • partially delayable at the origin
  • not dead at the destination

11
Motion Graph Completion
  • Create a single-source, single-sink graph
  • Create cost edges to account for predication
    overhead (side entries)

12
Code Motion
Remove original computation, set predicate
Clear predicate at side entries
Insert new computation on the cut edges
control-equivalent block, execute only when
predicate is set
13
Cyclic P3DE Example
14
Cyclic P3DE Motion Graph
15
Comparison Loop Variable Migration
  • The primary benefit of P3DE comes from register
    promotion within a loop with aliasing function
    calls, when performed with a similar speculative
    PRE operation
  • Bodik Ph.D. thesis 99
  • Within IMPACT, this optimization is already
    performed to some degree by loop variable
    migration, which guards individual aliasing
    function calls with loads and stores of the
    variable
  • However, P3DE speculative PRE is a more
    systematic method of performing this
    optimization, as it guards aliasing regions

16
Loop Variable Migration Example
17
Performance Evaluation
  • Test machine HP zx6000 workstation
  • dual Itanium 2, 1GHz processors
  • 8GB RAM
  • IMPACT compiler configuration
  • Andersens-style, context-sensitive,
    field-sensitive pointer analysis for memory
    disambiguation (incorporated after Ryoo M.S.
    thesis 04)
  • Traditional optimizations, loop optimizations
    (including loop variable migration), speculative
    PRE, hyperblock, and superblock formation
  • Baseline runs a sink-only-if-partially-delayable
    PDE prior to hyperblock and superblock formation
  • P3DE version replaces PDE in the optimization
    chain and does not run loop variable migration
  • SPEC scores taken as the median of 5 runs
  • Itanium performance counters used to measure
    stores and predicate write operations

18
Dynamic Store Operations Removed
stores normalized to baseline input
19
Predicate Writes Inserted Per Store Removed
Performed on a HP zx6000 with 2 Itanium 2 1GHz
processors and 8GB RAM
predicate writes per store removed
  • Some benchmarks omitted due to relatively small
    number of stores removed
  • Many predicate write operations are created by
    hyperblock formation, which can affect the total
    number of predicate write operations

20
SPEC Performance Increase
Performed on a HP zx6000 with 2 Itanium 2 1GHz
processors and 8GB RAM
percentage increase over baseline performance
21
Performance Analysis
  • Many profitable cases already subsumed by loop
    variable migration, so little effect seen in many
    benchmarks
  • 255.vortex achieves performance benefit
  • Specific losses
  • 186.crafty
  • micropipeline stalls loads and stores clustered
    together may appear to have conflicts
  • kernel cycles increase
  • 253.perlbmk explicit spill stores due to
    register pressure
  • 254.gap largest portion is branch misprediction

22
Conclusions
  • P3DE, in combination with speculative PRE, is a
    more systematic version of loop variable
    migration
  • P3DE improves performance when stores are moved
    out of the critical path of statically-scheduled
    regions
  • In a wide-issue architecture, instructions
    generally have significant scheduling freedom, so
    P3DE has little additional benefit on performance
    over loop variable migration, and can result in
  • Increased register pressure
  • Micropipeline stalls when moving stores towards
    loads
  • Perturbation of hyperblock formation
  • An undue amount of predication is not introduced
    (due to cost edges)
About PowerShow.com