Possible Extensions to DyC

This is a list of possible ways in which we could extend DyC. Some actually fall within our current design, but we haven't yet implemented. Others are ideas that are not yet fully fleshed out.

• Features
  • ^*Static annotation (@) for other unsafe operations, such as calls and divide
  • ^*Register actions
  • Split the graph for multiple divisions
  • Function annotations
  • promote_all_invalidate, promote_one_invalidate, and promote_one_invalidate_unchecked and explicit invalidation annotations
  • cache_one
  • cache(n)
  • Global space management / global cache policies
  • Program-point lazy annotation
  • Division querying
  • Run-time inlining
  • Data specialization
• Optimizations
  • ^*Multiflow's inlining for apps and for GE operations
  • ^*Investigate excessive spilling at trace boundaries
  • Static and dynamic IGOTOs
  • Move loads of live static variables to their uses
  • Discordant SELECTs (control-flow merge converted to data-flow merge; we should treat them equally; convert dynamic SELECTs of static operands back to control flow inside the BTA, saving enough state to revert if the binding times change)
  • Reduce scheduling constraints (eliminate use of trace boundaries to stop code motion)
  • Reduce caching overheads
    • Make cache_one_unchecked a single jump
    • Specialize lazy entries
    • Sort vectors of live static variables by size to reduce fragmentation
    • PIC-style cache lookups
    • Hierarchical-context-based caching
    • Choose optimal cache-context composition
  • Reachability conditions
  • Reduce work-list overhead
    • Peel / partially unroll the work-list loop
    • Eliminate redundant copying of static variables live across unit boundaries
  • Reduce unit-boundary crossings
    • Linearization
    • Clustering
    • Single-run-time-predecessor optimizations
  • Further optimize memory allocation
  • Eliminate redundant table-pointer construction
  • Overwrite jmps with brs
  • Eliminate branch laziness when possible
  • Scrap merger and generate the GEs in a second pass of the compiler; this would allow more scheduling constraints on the template code to be removed

Last updated October 1, 1997.
Brian Grant (grant@cs.washington.edu)