1. Conditionally Correct Superoptimization Rahul Sharma, Eric Schkufza, Berkeley Churchill, Alex Aiken (Stanford University)

2. Performance Many systems where code performance matters Compute-bound Repeatedly executed Scientific computing Graphics Low-latency server code Encryption/decryption … 2

3. x86 optimizations are hard x86 is a CISC instruction set Many complicated instructions E.g., dpp, popcnt, crc, … ~2000 instruction variants 3439 page manual x86 optimizations require expert knowledge Experts take hours, days, or even weeks For each new processor 3

4. Superoptimization Generate the optimum implementation Massalin [ASPLOS 87], Bansal and Aiken [ASPLOS 06] Enumerate all possible straight-line programs STOKE, Schkufza, Sharma, Aiken [ASPLOS 13] Random enumeration instead of exhaustive Transforms programs with loops Prove optimized program is equivalent to the original 4

5. Architecture Enumerator CHECKER Arbitrary Programs Correct Programs Perf. Tests Fast Correct Program 5 Massalin ‘87 checks correctness using tests Bansal and Aiken ‘06 use a SAT solver STOKE proves equivalence using DDEC [OOPSLA 13]

6. Verification Pros: Optimizations are formally verified Cons: Useful optimizations can be discarded Equivalence checker rejects many “good” programs Work perfectly with the application Fail on some weird corner case that cannot arise 6

7. Example Target foo(int32_t* a, int32_t* b) *a++=*b++; return; Expert Rewrite MOVAPD xmm0, [b] MOVAPD [a], xmm0 RET Incorrect, if a and b overlap Segfault if a and b are not 16 byte aligned 7

8. Conditions Cannot use the fast rewrite in an arbitrary context Developers know conditions on the context Used in adding unchecked annotations, writing assembly Unconditionally correct optimizations are effective But fall short of the fastest code desired For performance, we need conditional equivalence 8

9. Conditional correctness Target foo(int32_t* a, int32_t* b) *a++=*b++; return; Rewrite MOVAPD xmm0, [b] MOVAPD [a], xmm0 RET Conditionally correct restrict(a), restrict(b) a, b are 16 byte aligned 9

10. Conditionally correct optimizer Conditionally Correct Programs STOKE CHECKER Random Programs Tests Fast Conditionally Correct Program 10

11. Conditionally correct optimizer Data! 11 Conditionally Correct Programs STOKE CHECKER Random Programs Tests Fast Conditionally Correct Program

12. Condition inference Tests encode the conditions on contexts implicitly Learn facts about tests (Daikon style) Keep adding facts until the proof succeeds Aliasing: two memory dereferences do not alias Alignment: an address is x-byte aligned Equalities, inequalities, floating-point specific 12

13. Equivalence checking (loop- free) 13 Registers Memory Registers Memory

14. Equivalence checking (loops) 14 Registers Memory Registers Memory

15. Abstract interpretation 15

16. Conditions 16 Application (A) Target (T) Rewrite (R) Condition (C) 1.Analyze A to verify C 2.Manually verify C 3.Runtime check if (C) T R Yes No

17. Conditional GCC Annotations can help a compiler significantly 17

18. Conditional STOKE STOKE with condition inference is comparable or outperforms gcc with or without annotations 18

19. Runtime checks Overhead of condition checking can be bearable 19

20. Aliasing 20

21. Conclusion Optimizers are conservative about context Automatically infer preconditions from tests Formally verify conditional equivalence Significant performance improvements 21

22. Related work ParaScope [PPoPP ‘93], SUIF Explorer [PPoPP ‘99], IOPT [OOPSLA ‘09], … M. Kawaguchi, S. K. Lahiri, and H. Reblo: Conditional equivalence. TR, MSR, 2010. M. D. Ernst et al. The Daikon system for dynamic detection of likely invariants. Sci. Comput. Program., 2007 G. Yorsh, T. Ball, and M. Sagiv: Testing, abstraction, theorem proving: better together! ISSTA 2006 George C. Necula: Translation validation for an optimizing compiler. PLDI 2000 Henry Massalin: Superoptimizer - A Look at the Smallest Program. ASPLOS 1987 22