llvm.org GIT mirror llvm / 599a7dc
Add a few more performance tips These came from my own experience and may not apply equally to all use cases. Any alternate perspective anyone has should be used to refine these. As always, grammar and spelling adjustments are more than welcome. Please just directly commit a fix if you see something problematic. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@231352 91177308-0d34-0410-b5e6-96231b3b80d8 Philip Reames 4 years ago
2 changed file(s) with 59 addition(s) and 3 deletion(s). Raw diff Collapse all Expand all
5252 #. Make sure that a DataLayout is provided (this will likely become required in
5353 the near future, but is certainly important for optimization).
55 #. Add nsw/nuw/fast-math flags as appropriate
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. For languages which need overflow semantics,
58 consider using the :ref:`overflow intrinsics `.
60 #. Use fast-math flags on floating point operations if legal. If you don't
61 need strict IEEE floating point semantics, there are a number of additional
62 optimizations that can be performed. This can be highly impactful for
63 floating point intensive computations.
65 #. Use inbounds on geps. This can help to disambiguate some aliasing queries.
5767 #. Add noalias/align/dereferenceable/nonnull to function arguments and return
5868 values as appropriate
60 #. Mark functions as readnone/readonly/nounwind when known (especially for
61 external functions)
70 #. Mark functions as readnone/readonly or noreturn/nounwind when known. The
71 optimizer will try to infer these flags, but may not always be able to.
72 Manual annotations are particularly important for external functions that
73 the optimizer can not analyze.
6375 #. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
6476 analysis), prefer GEPs
8496 and may not be well optimized by the current optimizer. Depending on your
8597 source language, you may consider using fences instead.
99 #. If calling a function which is known to throw an exception (unwind), use
100 an invoke with a normal destination which contains an unreachable
101 instruction. This form conveys to the optimizer that the call returns
102 abnormally. For an invoke which neither returns normally or requires unwind
103 code in the current function, you can use a noreturn call instruction if
104 desired. This is generally not required because the optimizer will convert
105 an invoke with an unreachable unwind destination to a call instruction.
87107 #. If you language uses range checks, consider using the IRCE pass. It is not
88108 currently part of the standard pass order.
110 #. For languages with numerous rarely executed guard conditions (e.g. null
111 checks, type checks, range checks) consider adding an extra execution or
112 two of LoopUnswith and LICM to your pass order. The standard pass order,
113 which is tuned for C and C++ applications, may not be sufficient to remove
114 all dischargeable checks from loops.
116 #. Use profile metadata to indicate statically known cold paths, even if
117 dynamic profiling information is not available. This can make a large
118 difference in code placement and thus the performance of tight loops.
120 #. When generating code for loops, try to avoid terminating the header block of
121 the loop earlier than necessary. If the terminator of the loop header
122 block is a loop exiting conditional branch, the effectiveness of LICM will
123 be limited for loads not in the header. (This is due to the fact that LLVM
124 may not know such a load is safe to speculatively execute and thus can't
125 lift an otherwise loop invariant load unless it can prove the exiting
126 condition is not taken.) It can be profitable, in some cases, to emit such
127 instructions into the header even if they are not used along a rarely
128 executed path that exits the loop. This guidance specifically does not
129 apply if the condition which terminates the loop header is itself invariant,
130 or can be easily discharged by inspecting the loop index variables.
132 #. In hot loops, consider duplicating instructions from small basic blocks
133 which end in highly predictable terminators into their successor blocks.
134 If a hot successor block contains instructions which can be vectorized
135 with the duplicated ones, this can provide a noticeable throughput
136 improvement. Note that this is not always profitable and does involve a
137 potentially large increase in code size.
139 #. Avoid high in-degree basic blocks (e.g. basic blocks with dozens or hundreds
140 of predecessors). Among other issues, the register allocator is known to
141 perform badly with confronted with such structures. The only exception to
142 this guidance is that a unified return block with high in-degree is fine.
90144 p.s. If you want to help improve this document, patches expanding any of the
91145 above items into standalone sections of their own with a more complete
90549054 ``is_zero_undef == 0`` and ``undef`` otherwise. For example,
90559055 ``llvm.cttz(2) = 1``.
9057 .. _int_overflow:
90579059 Arithmetic with Overflow Intrinsics
90589060 -----------------------------------