llvm.org GIT mirror llvm / 1cc7934
[docs] Organize the 'Performance Tips' page This change just groups the suggestions by broad topic. I'm planning a couple of follow on changes to improve the readability of this document. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@245854 91177308-0d34-0410-b5e6-96231b3b80d8 Philip Reames 4 years ago
1 changed file(s) with 54 addition(s) and 46 deletion(s). Raw diff Collapse all Expand all
1414 and weaknesses. In some cases, surprisingly small changes in the source IR
1515 can have a large effect on the generated code.
1616
17 IR Best Practices
18 =================
19
1720 Avoid loads and stores of large aggregate type
18 ================================================
21 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1922
2023 LLVM currently does not optimize well loads and stores of large :ref:`aggregate
2124 types ` (i.e. structs and arrays). As an alternative, consider
2629 be an effective way to represent collections of small packed fields.
2730
2831 Prefer zext over sext when legal
29 ==================================
32 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
3033
3134 On some architectures (X86_64 is one), sign extension can involve an extra
3235 instruction whereas zero extension can be folded into a load. LLVM will try to
3841 ` and LLVM can do the sext to zext conversion for you.
3942
4043 Zext GEP indices to machine register width
41 ============================================
44 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
4245
4346 Internally, LLVM often promotes the width of GEP indices to machine register
4447 width. When it does so, it will default to using sign extension (sext)
4649 the range of the index, you may wish to manually extend indices to machine
4750 register width using a zext instruction.
4851
49 Other things to consider
50 =========================
52 Other Things to Consider
53 ^^^^^^^^^^^^^^^^^^^^^^^^
5154
5255 #. Make sure that a DataLayout is provided (this will likely become required in
5356 the near future, but is certainly important for optimization).
5457
55 #. Add nsw/nuw flags as appropriate. Reasoning about overflow is
56 generally hard for an optimizer so providing these facts from the frontend
57 can be very impactful.
58
59 #. Use fast-math flags on floating point operations if legal. If you don't
60 need strict IEEE floating point semantics, there are a number of additional
61 optimizations that can be performed. This can be highly impactful for
62 floating point intensive computations.
63
64 #. Use inbounds on geps. This can help to disambiguate some aliasing queries.
65
66 #. Add noalias/align/dereferenceable/nonnull to function arguments and return
67 values as appropriate
68
69 #. Mark functions as readnone/readonly or noreturn/nounwind when known. The
70 optimizer will try to infer these flags, but may not always be able to.
71 Manual annotations are particularly important for external functions that
72 the optimizer can not analyze.
73
7458 #. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
7559 analysis), prefer GEPs
7660
77 #. Use the lifetime.start/lifetime.end and invariant.start/invariant.end
78 intrinsics where possible. Common profitable uses are for stack like data
79 structures (thus allowing dead store elimination) and for describing
80 life times of allocas (thus allowing smaller stack sizes).
81
82 #. Use pointer aliasing metadata, especially tbaa metadata, to communicate
83 otherwise-non-deducible pointer aliasing facts
84
8561 #. Use the "most-private" possible linkage types for the functions being defined
8662 (private, internal or linkonce_odr preferably)
87
88 #. Mark invariant locations using !invariant.load and TBAA's constant flags
8963
9064 #. Prefer globals over inttoptr of a constant address - this gives you
9165 dereferencability information. In MCJIT, use getSymbolAddress to provide
10276 code in the current function, you can use a noreturn call instruction if
10377 desired. This is generally not required because the optimizer will convert
10478 an invoke with an unreachable unwind destination to a call instruction.
105
106 #. If you language uses range checks, consider using the IRCE pass. It is not
107 currently part of the standard pass order.
108
109 #. For languages with numerous rarely executed guard conditions (e.g. null
110 checks, type checks, range checks) consider adding an extra execution or
111 two of LoopUnswith and LICM to your pass order. The standard pass order,
112 which is tuned for C and C++ applications, may not be sufficient to remove
113 all dischargeable checks from loops.
11479
11580 #. Use profile metadata to indicate statically known cold paths, even if
11681 dynamic profiling information is not available. This can make a large
163128 time and optimization effectiveness. The former is fixable with enough
164129 effort, but the later is fairly fundamental to their designed purpose.
165130
166 p.s. If you want to help improve this document, patches expanding any of the
167 above items into standalone sections of their own with a more complete
168 discussion would be very welcome.
169131
132 Describing Language Specific Properties
133 =======================================
134
135 When translating a source language to LLVM, finding ways to express concepts and guarantees available in your source language which are not natively provided by LLVM IR will greatly improve LLVM's ability to optimize your code. As an example, C/C++'s ability to mark every add as "no signed wrap (nsw)" goes along way to assisting the optimizer in reasoning about loop induction variables.
136
137 The LLVM LangRef includes a number of mechanisms for annotating the IR with additional semantic information. It is *strongly* recommended that you become highly familiar with this document. The list below is intended to highlight a couple of items of particular interest, but is by no means exhaustive.
138
139 #. Add nsw/nuw flags as appropriate. Reasoning about overflow is
140 generally hard for an optimizer so providing these facts from the frontend
141 can be very impactful.
142
143 #. Use fast-math flags on floating point operations if legal. If you don't
144 need strict IEEE floating point semantics, there are a number of additional
145 optimizations that can be performed. This can be highly impactful for
146 floating point intensive computations.
147
148 #. Use inbounds on geps. This can help to disambiguate some aliasing queries.
149
150 #. Add noalias/align/dereferenceable/nonnull to function arguments and return
151 values as appropriate
152
153 #. Mark functions as readnone/readonly or noreturn/nounwind when known. The
154 optimizer will try to infer these flags, but may not always be able to.
155 Manual annotations are particularly important for external functions that
156 the optimizer can not analyze.
157
158 #. Use the lifetime.start/lifetime.end and invariant.start/invariant.end
159 intrinsics where possible. Common profitable uses are for stack like data
160 structures (thus allowing dead store elimination) and for describing
161 life times of allocas (thus allowing smaller stack sizes).
162
163 #. Use pointer aliasing metadata, especially tbaa metadata, to communicate
164 otherwise-non-deducible pointer aliasing facts
165
166 #. Mark invariant locations using !invariant.load and TBAA's constant flags
167
168 #. If you language uses range checks, consider using the IRCE pass. It is not
169 currently part of the standard pass order.
170
171 #. For languages with numerous rarely executed guard conditions (e.g. null
172 checks, type checks, range checks) consider adding an extra execution or
173 two of LoopUnswith and LICM to your pass order. The standard pass order,
174 which is tuned for C and C++ applications, may not be sufficient to remove
175 all dischargeable checks from loops.
176
177 If you didn't find what you were looking for above, consider proposing an piece of metadata which provides the optimization hint you need. Such extensions are relatively common and are generally well received by the community. You will need to ensure that your proposal is sufficiently general so that it benefits others if you wish to contribute it upstream.
170178
171179 Adding to this document
172180 =======================