llvm.org GIT mirror llvm / 506ace9
[docs][PerformanceTips] Framing the generic IR tips git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245858 91177308-0d34-0410-b5e6-96231b3b80d8 Philip Reames 4 years ago
1 changed file(s) with 32 addition(s) and 14 deletion(s). Raw diff Collapse all Expand all
1010
1111 The intended audience of this document is developers of language frontends
1212 targeting LLVM IR. This document is home to a collection of tips on how to
13 generate IR that optimizes well. As with any optimizer, LLVM has its strengths
14 and weaknesses. In some cases, surprisingly small changes in the source IR
15 can have a large effect on the generated code.
13 generate IR that optimizes well.
1614
1715 IR Best Practices
1816 =================
17
18 As with any optimizer, LLVM has its strengths and weaknesses. In some cases,
19 surprisingly small changes in the source IR can have a large effect on the
20 generated code.
21
22 Beyond the specific items on the list below, it's worth noting that the most
23 mature frontend for LLVM is Clang. As a result, the further your IR gets from what Clang might emit, the less likely it is to be effectively optimized. It
24 can often be useful to write a quick C program with the semantics you're trying
25 to model and see what decisions Clang's IRGen makes about what IR to emit.
26 Studying Clang's CodeGen directory can also be a good source of ideas. Note
27 that Clang and LLVM are explicitly version locked so you'll need to make sure
28 you're using a Clang built from the same svn revision or release as the LLVM
29 library you're using. As always, it's *strongly* recommended that you track
30 tip of tree development, particularly during bring up of a new project.
31
32 The Basics
33 ^^^^^^^^^^^
34
35 #. Make sure that your Modules contain both a data layout specification and
36 target triple. Without these pieces, non of the target specific optimization
37 will be enabled. This can have a major effect on the generated code quality.
38
39 #. For each function or global emitted, use the most private linkage type
40 possible (private, internal or linkonce_odr preferably). Doing so will
41 make LLVM's inter-procedural optimizations much more effective.
42
43 #. Avoid high in-degree basic blocks (e.g. basic blocks with dozens or hundreds
44 of predecessors). Among other issues, the register allocator is known to
45 perform badly with confronted with such structures. The only exception to
46 this guidance is that a unified return block with high in-degree is fine.
47
1948
2049 Avoid loads and stores of large aggregate type
2150 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
5281 Other Things to Consider
5382 ^^^^^^^^^^^^^^^^^^^^^^^^
5483
55 #. Make sure that a DataLayout is provided (this will likely become required in
56 the near future, but is certainly important for optimization).
57
5884 #. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
5985 analysis), prefer GEPs
60
61 #. Use the "most-private" possible linkage types for the functions being defined
62 (private, internal or linkonce_odr preferably)
6386
6487 #. Prefer globals over inttoptr of a constant address - this gives you
6588 dereferencability information. In MCJIT, use getSymbolAddress to provide
100123 improvement. Note that this is not always profitable and does involve a
101124 potentially large increase in code size.
102125
103 #. Avoid high in-degree basic blocks (e.g. basic blocks with dozens or hundreds
104 of predecessors). Among other issues, the register allocator is known to
105 perform badly with confronted with such structures. The only exception to
106 this guidance is that a unified return block with high in-degree is fine.
107
108126 #. When checking a value against a constant, emit the check using a consistent
109127 comparison type. The GVN pass *will* optimize redundant equalities even if
110128 the type of comparison is inverted, but GVN only runs late in the pipeline.