1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
|
=====================================
Performance Tips for Frontend Authors
=====================================
.. contents::
:local:
:depth: 2
Abstract
========
The intended audience of this document is developers of language frontends
targeting LLVM IR. This document is home to a collection of tips on how to
generate IR that optimizes well. As with any optimizer, LLVM has its strengths
and weaknesses. In some cases, surprisingly small changes in the source IR
can have a large effect on the generated code.
Avoid loads and stores of large aggregate type
================================================
LLVM currently does not optimize well loads and stores of large :ref:`aggregate
types <t_aggregate>` (i.e. structs and arrays). As an alternative, consider
loading individual fields from memory.
Aggregates that are smaller than the largest (performant) load or store
instruction supported by the targeted hardware are well supported. These can
be an effective way to represent collections of small packed fields.
Prefer zext over sext when legal
==================================
On some architectures (X86_64 is one), sign extension can involve an extra
instruction whereas zero extension can be folded into a load. LLVM will try to
replace a sext with a zext when it can be proven safe, but if you have
information in your source language about the range of a integer value, it can
be profitable to use a zext rather than a sext.
Alternatively, you can :ref:`specify the range of the value using metadata
<range-metadata>` and LLVM can do the sext to zext conversion for you.
Zext GEP indices to machine register width
============================================
Internally, LLVM often promotes the width of GEP indices to machine register
width. When it does so, it will default to using sign extension (sext)
operations for safety. If your source language provides information about
the range of the index, you may wish to manually extend indices to machine
register width using a zext instruction.
Other things to consider
=========================
#. Make sure that a DataLayout is provided (this will likely become required in
the near future, but is certainly important for optimization).
#. Add nsw/nuw flags as appropriate. Reasoning about overflow is
generally hard for an optimizer so providing these facts from the frontend
can be very impactful. For languages which need overflow semantics,
consider using the :ref:`overflow intrinsics <int_overflow>`.
#. Use fast-math flags on floating point operations if legal. If you don't
need strict IEEE floating point semantics, there are a number of additional
optimizations that can be performed. This can be highly impactful for
floating point intensive computations.
#. Use inbounds on geps. This can help to disambiguate some aliasing queries.
#. Add noalias/align/dereferenceable/nonnull to function arguments and return
values as appropriate
#. Mark functions as readnone/readonly or noreturn/nounwind when known. The
optimizer will try to infer these flags, but may not always be able to.
Manual annotations are particularly important for external functions that
the optimizer can not analyze.
#. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
analysis), prefer GEPs
#. Use the lifetime.start/lifetime.end and invariant.start/invariant.end
intrinsics where possible. Common profitable uses are for stack like data
structures (thus allowing dead store elimination) and for describing
life times of allocas (thus allowing smaller stack sizes).
#. Use pointer aliasing metadata, especially tbaa metadata, to communicate
otherwise-non-deducible pointer aliasing facts
#. Use the "most-private" possible linkage types for the functions being defined
(private, internal or linkonce_odr preferably)
#. Mark invariant locations using !invariant.load and TBAA's constant flags
#. Prefer globals over inttoptr of a constant address - this gives you
dereferencability information. In MCJIT, use getSymbolAddress to provide
actual address.
#. Be wary of ordered and atomic memory operations. They are hard to optimize
and may not be well optimized by the current optimizer. Depending on your
source language, you may consider using fences instead.
#. If calling a function which is known to throw an exception (unwind), use
an invoke with a normal destination which contains an unreachable
instruction. This form conveys to the optimizer that the call returns
abnormally. For an invoke which neither returns normally or requires unwind
code in the current function, you can use a noreturn call instruction if
desired. This is generally not required because the optimizer will convert
an invoke with an unreachable unwind destination to a call instruction.
#. If you language uses range checks, consider using the IRCE pass. It is not
currently part of the standard pass order.
#. For languages with numerous rarely executed guard conditions (e.g. null
checks, type checks, range checks) consider adding an extra execution or
two of LoopUnswith and LICM to your pass order. The standard pass order,
which is tuned for C and C++ applications, may not be sufficient to remove
all dischargeable checks from loops.
#. Use profile metadata to indicate statically known cold paths, even if
dynamic profiling information is not available. This can make a large
difference in code placement and thus the performance of tight loops.
#. When generating code for loops, try to avoid terminating the header block of
the loop earlier than necessary. If the terminator of the loop header
block is a loop exiting conditional branch, the effectiveness of LICM will
be limited for loads not in the header. (This is due to the fact that LLVM
may not know such a load is safe to speculatively execute and thus can't
lift an otherwise loop invariant load unless it can prove the exiting
condition is not taken.) It can be profitable, in some cases, to emit such
instructions into the header even if they are not used along a rarely
executed path that exits the loop. This guidance specifically does not
apply if the condition which terminates the loop header is itself invariant,
or can be easily discharged by inspecting the loop index variables.
#. In hot loops, consider duplicating instructions from small basic blocks
which end in highly predictable terminators into their successor blocks.
If a hot successor block contains instructions which can be vectorized
with the duplicated ones, this can provide a noticeable throughput
improvement. Note that this is not always profitable and does involve a
potentially large increase in code size.
#. Avoid high in-degree basic blocks (e.g. basic blocks with dozens or hundreds
of predecessors). Among other issues, the register allocator is known to
perform badly with confronted with such structures. The only exception to
this guidance is that a unified return block with high in-degree is fine.
p.s. If you want to help improve this document, patches expanding any of the
above items into standalone sections of their own with a more complete
discussion would be very welcome.
Adding to this document
=======================
If you run across a case that you feel deserves to be covered here, please send
a patch to `llvm-commits
<http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_ for review.
If you have questions on these items, please direct them to `llvmdev
<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_. The more relevant
context you are able to give to your question, the more likely it is to be
answered.
|
