1 / 17

SoftSig: Software-Exposed Hardware Signatures for Code Analysis and Optimizations

This paper presents a novel framework called SoftSig, which exposes hardware signatures to improve code analysis and optimizations at runtime. By leveraging multiple hardware watch-points and contextual disambiguation of address sets, this method addresses limitations in current compile-time analysis. Key aspects include reducing software register accesses, memory access management, and utilizing memoization to enhance efficiency. The proposed design guidelines emphasize correctness and efficiency, ensuring robust memory disambiguation while optimizing performance in software-hardware interactions.

jola
Download Presentation

SoftSig: Software-Exposed Hardware Signatures for Code Analysis and Optimizations

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SoftSig: Software-Exposed Hardware Signatures for Code Analysis and Optimizations UIUC – ASPLOS 2008 by Evangelos Vlachos

  2. Motivation • Runtime Disambiguation of Sets of Addresses • Multiple Hardware watch-points • Inter-thread dependencies (e.g., TLS, TM) • Compile-time analysis too limited • Previous solutions • Compare address to an associative structure • Operate on sets of addresses (signatures)

  3. Propose • Hardware signatures • Perform multiple operations at a time • Too simple software interface so far (TM) • Expose hw signatures to software • Software flexibility: decides on • Memory accesses to collect • Memory accesses to disambiguate against • Software Register File (SFR) & Sophisticated ISA

  4. Background • 1) • 2) Memoization • Don’t compute same result again – Remember it

  5. Examples

  6. Design Guidelines • G1: Minimize SR accesses and copies • SR size = 1Kbit • Context switch – discard SRs • Never spill SR to stack

  7. Design Guidelines • G1: Minimize SR accesses and copies • G2: Manage the SRF through dynamic allocation • Limited number of SRs • Hard-to-predict lifetimes

  8. Design Guidelines • G1: Minimize SR accesses and copies • G2: Manage the SRF through dynamic allocation • G3: Imprecision should never compromise correctness • Software that uses SR must be able to overcome false positives

  9. Design Guidelines • G1: Minimize SR accesses and copies • G2: Manage the SRF through dynamic allocation • G3: Imprecision should never compromise correctness • G4: Manage imprecision to provide the most efficiency • Shorter ranges & filter some of the addresses

  10. ISA extensions

  11. SoftSig Architecture

  12. Collection & Local Disambiguation • bcollect or bdisamb.loc • Notify LSQ to send addresses to SPM • If no conflict, the instruction can retire • ecollect and edisamb.loc • Stop collecting and disambiguating addresses

  13. Remote Disambiguation • When is an address disambiguated? • ICD = In-flight Conflict Detector • What about cache displacements?

  14. Example: Memoization Framework • Identify redundant calls • Remember inputs & outputs • Collect implicit inputs & outputs • Check to see if implicit in/out get modified • Don’t perform next call if no conflict is found – Memoized

  15. Example: Memoization Framework • Prologue: Avoid Function call? • Compare explicit in/out with the ones memoized • See if there was a conflict • Setup: Cannot avoid it • Remember in/out • Allocate SR • Epilogue • Finish setting up

  16. Evaluation

  17. Evaluation

More Related