A whirlwind tour of the LLVM optimizer
5 likes7,958 views
This document presents a detailed overview of the LLVM optimizer, specifically focusing on the middle-end optimization pipeline and important optimization passes. It discusses various techniques such as module simplification, control-flow optimization, instruction combining, and memory optimizations, providing insights into how different passes interact within the optimization process. Additionally, it outlines the responsibilities and constraints of key optimization passes used in LLVM, as well as examples of optimization strategies employed.
![SimplifyCFG: Switch to lookup table
switch (x) {
case 0:
return 10;
case 1:
return 42;
case 2:
return 123;
case 3:
return 7;
default:
return 13;
}
42
int table[] = {10, 42, 123, 7};
if (x < 4) {
return table[x];
} else {
return 13;
}](https://image.slidesharecdn.com/awhirlwindtourofthellvmoptimizer-230510155843-c30751d5/85/A-whirlwind-tour-of-the-LLVM-optimizer-42-320.jpg)
A whirlwind tour of the LLVM optimizer
- 1. A whirlwind tour of the LLVM optimizer Nikita Popov @ EuroLLVM 2023
- 2. Agenda ● High-level overview of the middle-end optimization pipeline ● Brief description of important optimization passes ○ Get basic idea about pass responsibilities ○ Learn about key restrictions/constraints 2
- 3. About Me ● Software Engineer on Platform Tools team at Red Hat ○ Packaging of LLVM for Fedora, CentOS and RHEL ○ Upstream work on LLVM and Clang 3
- 4. About Me ● Software Engineer on Platform Tools team at Red Hat ○ Packaging of LLVM for Fedora, CentOS and RHEL ○ Upstream work on LLVM and Clang ● I work on: ○ The LLVM middle-end ○ LLVM / Rust integration ○ Compilation time improvements (LLVM Compile-Time Tracker) 4
- 6. Default (non-LTO) pipeline 6 Module 1 Module 1' Optimize Module 2 Module 2' Module 3 Module 3'
- 7. Full LTO pipeline 7 Module 1 Module 1' Pre-link optimize Module 2 Module 2' Module 3 Module 3' Module M Module M' Post-link optimize Merge
- 8. Thin LTO pipeline 8 Module 1 Module 1' Pre-link optimize Module 2 Module 2' Module 3 Module 3' Module 2'' Module 2''' Post-link optimize Cross import Module 1'' Module 3'' Module 3''' Module 1'''
- 10. Default pipeline 10 Module Simplification Module Optimization Backend More canonical Less canonical
- 11. Default pipeline 11 Module Simplification Module Optimization Backend More canonical Less canonical Inlining Mem2Reg LICM (Loop Invariant Code Motion) ... Make further opts easier
- 12. Default pipeline 12 Module Simplification Module Optimization Backend More canonical Less canonical Vectorization Runtime unrolling ... Make further opts harder Inlining Mem2Reg LICM ... Make further opts easier
- 13. Default pipeline 13 Module Simplification Module Optimization Backend More canonical Less canonical Vectorization Runtime unrolling ... Make further opts harder Inlining Mem2Reg LICM ... Make further opts easier Target-specific optimization Lowering to machine code
- 14. ThinLTO pipeline 14 Module 1 Simplification Module 1' Simplification Module 1' Optimization Module 2 Simplification Module 2' Simplification Module 2' Optimization Cross import Post-link Pre-link
- 15. ThinLTO pipeline 15 Module 1 Simplification Module 1' Simplification Module 1' Optimization Module 2 Simplification Module 2' Simplification Module 2' Optimization Cross import Post-link Pre-link Second round of inlining
- 16. ThinLTO pipeline 16 Module 1 Simplification Module 1' Simplification Module 1' Optimization Module 2 Simplification Module 2' Simplification Module 2' Optimization Cross import Post-link Pre-link Second round of inlining Don't run decanonicalizing transforms pre-link
- 17. Module Simplification 17 Early Cleanup Inlining Function Simplification Late Cleanup CGSCC Pipeline
- 22. CGSCC Pipeline 22 g,h i f simplify try inline simplify try inline simplify
- 23. CGSCC Pipeline 23 g,h i f simplify try inline simplify try inline simplify Inlining sees already simplified functions!
- 24. Call-Graph Strongly Connected Components 24 g h i f SCC 1 SCC 2 SCC 3 No well-defined order within SCC
- 25. Running pipelines ● opt -passes='default<O3>' == opt -O3 ● opt -passes='thinlto-pre-link<O3>' ● opt -passes='thinlto<O3>' ● opt -passes='lto-pre-link<O3>' ● opt -passes='lto<O3>' 25
- 27. godbolt.org – LLVM Opt Pipeline 27
- 28. godbolt.org – LLVM Opt Pipeline 28
- 29. godbolt.org – LLVM Opt Pipeline 29 Or run opt -print-after-all locally
- 30. 30
- 32. Mem2Reg int test(int x, int y) { return x + y; } 32
- 33. Mem2Reg define i32 @test(i32 %x, i32 %y) { entry: %x.addr = alloca i32 %y.addr = alloca i32 store i32 %x, ptr %x.addr store i32 %y, ptr %y.addr %0 = load i32, ptr %x.addr %1 = load i32, ptr %y.addr %add = add nsw i32 %0, %1 ret i32 %add } 33
- 34. Mem2Reg define i32 @test(i32 %x, i32 %y) { entry: %add = add nsw i32 %x, %y ret i32 %add } 34
- 35. SROA: Scalar Replacement of Aggregates ● Break up allocas into smaller allocas based on access pattern ○ %vec = alloca { ptr, i64, i64 } ○ -> %vec.ptr = alloca ptr ○ -> %vec.size = alloca i64 ○ -> %vec.capacity = alloca i64 35
- 36. SROA: Scalar Replacement of Aggregates ● Break up allocas into smaller allocas based on access pattern ○ %vec = alloca { ptr, i64, i64 } ○ -> %vec.ptr = alloca ptr ○ -> %vec.size = alloca i64 ○ -> %vec.capacity = alloca i64 ● Then run Mem2Reg to convert alloca/load/store to SSA values 36
- 37. SROA: Scalar Replacement of Aggregates ● Break up allocas into smaller allocas based on access pattern ○ %vec = alloca { ptr, i64, i64 } ○ -> %vec.ptr = alloca ptr ○ -> %vec.size = alloca i64 ○ -> %vec.capacity = alloca i64 ● Then run Mem2Reg to convert alloca/load/store to SSA values ● Knows many tricks for overlapping accesses ○ For example inserting/extracting bits of a larger integer 37
- 39. SimplifyCFG ● The kitchen sink of control-flow transforms ○ If it fits nowhere else, put it here! 39
- 40. SimplifyCFG: Hoist if (cond) { foo(); a(); } else { foo(); b(); } 40 foo(); if (cond) { a(); } else { b(); }
- 41. SimplifyCFG: Speculate if (cond) { x = foo(); } else { x = 0; } 41 tmp = foo(); x = cond ? tmp : 0;
- 42. SimplifyCFG: Switch to lookup table switch (x) { case 0: return 10; case 1: return 42; case 2: return 123; case 3: return 7; default: return 13; } 42 int table[] = {10, 42, 123, 7}; if (x < 4) { return table[x]; } else { return 13; }
- 43. SimplifyCFG ● The kitchen sink of control-flow transforms ○ If it fits nowhere else, put it here! ● Invoked with many different options at different pipeline positions ○ Some transforms only run late in the pipeline 43
- 44. SimplifyCFG ● The kitchen sink of control-flow transforms ○ If it fits nowhere else, put it here! ● Invoked with many different options at different pipeline positions ○ Some transforms only run late in the pipeline ● Can use target-dependent cost model (via TargetTransformInfo) 44
- 46. InstCombine ● The kitchen sink of non-CFG transforms ○ If it fits nowhere else, put it here! 46
- 47. InstCombine: Analysis helpers 47 InstCombine InstSimplify ConstantFolding
- 48. InstCombine: Analysis helpers ● ConstantFolding ○ Folds instructions with constant operands to constants ○ 1 + 2 => 3 48
- 49. InstCombine: Analysis helpers ● ConstantFolding ○ Folds instructions with constant operands to constants ○ 1 + 2 => 3 ● InstSimplify ○ Folds instructions to existing values or constants ○ x + 0 => x ○ x - x => 0 49
- 50. InstCombine: Analysis helpers ● ConstantFolding ○ Folds instructions with constant operands to constants ○ 1 + 2 => 3 ● InstSimplify ○ Folds instructions to existing values or constants ○ x + 0 => x ○ x - x => 0 ● InstCombine ○ Tries constant folding and instruction simplification first ○ Performs folds that create or modify instructions ○ x * 4 => x << 2 50
- 51. InstCombine ● The kitchen sink of non-CFG transforms ○ If it fits nowhere else, put it here! ○ Use InstSimplify / ConstantFolding for transforms that don't create/modify instructions. 51
- 52. InstCombine ● The kitchen sink of non-CFG transforms ○ If it fits nowhere else, put it here! ○ Use InstSimplify / ConstantFolding for transforms that don't create/modify instructions. ● Also used to paper over phase ordering issues ○ InstCombine re-implements weak versions of transforms from other passes ○ For example: Basic store-to-load forwarding (usually done by EarlyCSE/GVN) 52
- 53. …Combine ● InstCombine ○ Canonicalization pass: Cannot be target-dependent ○ Backend implements reverse/undo transform if necessary 53
- 54. …Combine ● InstCombine ○ Canonicalization pass: Cannot be target-dependent ○ Backend implements reverse/undo transform if necessary ● AggressiveInstCombine ○ For expensive transforms, only runs once in pipeline ○ Target-dependence discouraged but sometimes allowed 54
- 55. …Combine ● InstCombine ○ Canonicalization pass: Cannot be target-dependent ○ Backend implements reverse/undo transform if necessary ● AggressiveInstCombine ○ For expensive transforms, only runs once in pipeline ○ Target-dependence discouraged but sometimes allowed ● VectorCombine ○ For target-dependent, cost-model driven vector transforms 55
- 56. CVP: CorrelatedValuePropagation ● Optimizations based on value range information (from LazyValueInfo) ● Important for bounds check elimination ○ icmp ult i32 %x, 10 => i1 true if %x in [0, 10) 56
- 57. CVP: CorrelatedValuePropagation ● Optimizations based on value range information (from LazyValueInfo) ● Important for bounds check elimination ○ icmp ult i32 %x, 10 => i1 true if %x in [0, 10) ● Other range based optimizations ○ sdiv i32 %x, %y => udiv i32 %x, %y if %x, %y non-negative 57
- 58. Same transform, different analysis 58 ● Some folds (e.g. sdiv -> udiv) are implemented in multiple passes ○ Folds are driven by different analyses, which are good at different things
- 59. Same transform, different analysis 59 InstCombine ValueTracking (KnownBits) CorrelatedValue Propagation LazyValueInfo IndVarSimplify ScalarEvolution IPSCCP ValueLattice + PredicateInfo ● Some folds (e.g. sdiv -> udiv) are implemented in multiple passes ○ Folds are driven by different analyses, which are good at different things
- 61. EarlyCSE: Common Subexpression Elimination 61 add1 = x + y; // ... add2 = x + y; use(add1); use(add2); add1 = x + y; // ... use(add1); use(add1);
- 62. EarlyCSE: Common Subexpression Elimination ● Basic CSE based on scoped hash table ● Load CSE and store-to-load forwarding using MemorySSA 62
- 63. EarlyCSE: Store to load forwarding 63 *p = v1; // p not written here v2 = *p; use(v1); use(v2); *p = v1; use(v1); use(v1);
- 64. GVN: Global Value Numbering ● More general (and much more expensive!) than EarlyCSE ● Uses MemoryDependenceAnalysis ● Non-local load CSE ● Partial redundancy elimination (PRE) 64
- 65. GVN: Non-local load CSE 65 if (...) { v1 = *p; } else { *p = v2; } v3 = *p; use(v3); if (...) { v1 = *p; } else { *p = v2; } v3 = phi(v1, v2); use(v3);
- 66. GVN: Load PRE 66 if (...) { } else { *p = v1; } v2 = *p; use(v2); if (...) { v2_pre = *p; } else { *p = v1; } v2 = phi(v2_pre, v1); use(v2);
- 68. MemCpyOpt ● Optimize memcpy and memset using MemorySSA 68
- 69. MemCpyOpt: Memcpy forwarding 69 memcpy(y, x, 16); // y not written here memcpy(z, y, 16); memcpy(y, x, 16); // y not written here memcpy(z, x, 16);
- 70. MemCpyOpt: Call Slot Optimization 70 Ty tmp; foo(tmp); memcpy(dst, tmp, sizeof(Ty)); foo(dst);
- 71. DSE: Dead Store Elimination ● Remove dead stores using MemorySSA 71
- 72. DSE: Dead Store Elimination 72 *p = v1; // p not read here *p = v2; // p not read here *p = v2;
- 73. DSE: Dead before return 73 %p = alloca i32 ; ... store i32 %v, ptr %p ; %p not read here ret void %p = alloca i32 ; ... ; %p not read here ret void
- 75. Loop pass manager ● Visit child loops first, then parent loops ● Constructs LoopSimplify and LCSSA (Loop-Closed SSA) form before running 75
- 76. 76 Preheader Exit Loop LICM: Hoist x = foo(); use(x); y = bar(); use(y);
- 77. 77 Preheader Exit Loop LICM: Hoist use(x); y = bar(); use(y); x = foo();
- 78. 78 Preheader Exit Loop LICM: Sink use(x); y = bar(); use(y); x = foo();
- 79. 79 Preheader Exit Loop LICM: Sink use(x); y = bar(); use(y); x = foo();
- 80. 80 Preheader Exit Loop LICM: Promote v = *p; vn = v + 1; *p = vn;
- 81. 81 Preheader Exit Loop LICM: Promote v = phi(v0, vn); vn = v + 1; *p = vn; v0 = *p;
- 82. LICM: Loop Invariant Code Motion ● Transforms: ○ Hoist instructions into preheader ○ Sink instructions into exits ○ Promote scalars ● Uses MemorySSA ● Canonicalization pass: Cannot be target or PGO dependent ○ May be undone by LoopSink or MachineSink 82
- 83. IndVarSimplify ● Uses ScalarEvolution analysis ● Simplify induction variables (IVs) and their uses ● Simplify loop exit conditions 83
- 84. IndVarSimplify: Loop exit value replacement unsigned test(unsigned n) { unsigned sum = 0; for (unsigned i = 0; i <= n; i++) { sum += i; } return sum; } 84
- 85. IndVarSimplify: Loop exit value replacement unsigned test(unsigned n) { unsigned sum = 0; for (unsigned i = 0; i <= n; i++) { sum += i; } return sum; } unsigned test(unsigned n) { for (unsigned i = 0; i <= n; i++) {} return (n * (n - 1))/2 + n; } 85
- 86. IndVarSimplify: Loop exit value replacement unsigned test(unsigned n) { unsigned sum = 0; for (unsigned i = 0; i <= n; i++) { sum += i; } return sum; } unsigned test(unsigned n) { for (unsigned i = 0; i <= n; i++) {} return (n * (n - 1))/2 + n; } 86 Later removed by LoopDeletion
- 87. LoopUnroll: Full unrolling 87 Iteration #1 Iteration #2 Iteration #3 Iteration #4 Iteration #1-4
- 88. LoopUnroll: Loop peeling 88 Iteration #1-N Iteration #1 Iteration #2-N
- 89. LoopUnroll: Partial unrolling 89 Iteration #(4i+1) Iteration #(4i+2) Iteration #(4i+3) Iteration #(4i+4) Iteration #1-400
- 90. LoopUnroll: Runtime unrolling 90 Iteration #(4i+1) Iteration #(4i+2) Iteration #(4i+3) Iteration #(4i+4) Iteration #1-N Tail iterations
- 91. LoopUnroll ● Simplification: ○ Full unrolling (requires known constant trip count) ○ Loop peeling ● Optimization: ○ Partial unrolling (requires known constant trip count/multiple) ○ Runtime unrolling 91
- 92. Vectorization 92
- 93. LoopVectorize ● VPlan to model vectorization without IR changes ● LoopAccessAnalysis to ensure memory dependences are safe ● May require inserting runtime checks and LoopVersioning 93
- 94. SLPVectorize ● SLP = Superword-Level Parallelism ● Vectorizes straight-line code 94
- 96. FunctionAttrs ● Infer attributes on function, arguments and return values ○ nounwind, readonly, nonnull, etc. 96
- 97. FunctionAttrs ● Infer attributes on function, arguments and return values ○ nounwind, readonly, nonnull, etc. ● General approach: ○ Optimistically all functions in the SCC are nounwind ○ Check whether there are any non-nounwind instructions ○ If not, mark all functions in the SCC nounwind 97
- 98. FunctionAttrs ● Infer attributes on function, arguments and return values ○ nounwind, readonly, nonnull, etc. ● General approach: ○ Optimistically all functions in the SCC are nounwind ○ Check whether there are any non-nounwind instructions ○ If not, mark all functions in the SCC nounwind ● New "Attributor" implements much stronger version of this, but not enabled by default (too slow) 98
- 99. IPSCCP: Inter-Procedural Sparse Conditional Constant Propagation ● Propagates constants and constant ranges across functions ● Uses PredicateInfo to take branch conditions into account 99
- 100. IPSCCP: Inter-Procedural Sparse Conditional Constant Propagation ● Propagates constants and constant ranges across functions ● Uses PredicateInfo to take branch conditions into account ● Runs very early, before most simplification (which may lose information) 100
- 101. IPSCCP: Inter-Procedural Sparse Conditional Constant Propagation ● Propagates constants and constant ranges across functions ● Uses PredicateInfo to take branch conditions into account ● Runs very early, before most simplification (which may lose information) ● Also does function specialization (since recently) 101
- 103. The End ● Blog: https://www.npopov.com/ ● Reach me at: ○ npopov@redhat.com ○ https://twitter.com/nikita_ppv 103
- 104. Bonus Slides 104
- 105. JumpThreading 105 if (x > 10) { greater10(); } always(); if (x > 0) { greater0(); } if (x > 10) { greater10(); always(); greater0(); } else { always(); }
- 106. JumpThreading ● Optimizes conditional branches where one condition implies another ● Uses LazyValueInfo analysis, which provides value range information 106
- 109. SimpleLoopUnswitch while (...) { if (c) { foo(); } else { bar(); } } 109 if (c) { while (...) { foo(); } } else { while (...) { bar(); } }