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

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