1 =====================================
2 Performance Tips for Frontend Authors
3 =====================================
12 The intended audience of this document is developers of language frontends
13 targeting LLVM IR. This document is home to a collection of tips on how to
14 generate IR that optimizes well. As with any optimizer, LLVM has its strengths
15 and weaknesses. In some cases, surprisingly small changes in the source IR
16 can have a large effect on the generated code.
18 Avoid loads and stores of large aggregate type
19 ================================================
21 LLVM currently does not optimize well loads and stores of large :ref:`aggregate
22 types <t_aggregate>` (i.e. structs and arrays). As an alternative, consider
23 loading individual fields from memory.
25 Aggregates that are smaller than the largest (performant) load or store
26 instruction supported by the targeted hardware are well supported. These can
27 be an effective way to represent collections of small packed fields.
29 Prefer zext over sext when legal
30 ==================================
32 On some architectures (X86_64 is one), sign extension can involve an extra
33 instruction whereas zero extension can be folded into a load. LLVM will try to
34 replace a sext with a zext when it can be proven safe, but if you have
35 information in your source language about the range of a integer value, it can
36 be profitable to use a zext rather than a sext.
38 Alternatively, you can :ref:`specify the range of the value using metadata
39 <range-metadata>` and LLVM can do the sext to zext conversion for you.
41 Zext GEP indices to machine register width
42 ============================================
44 Internally, LLVM often promotes the width of GEP indices to machine register
45 width. When it does so, it will default to using sign extension (sext)
46 operations for safety. If your source language provides information about
47 the range of the index, you may wish to manually extend indices to machine
48 register width using a zext instruction.
50 Other things to consider
51 =========================
53 #. Make sure that a DataLayout is provided (this will likely become required in
54 the near future, but is certainly important for optimization).
56 #. Add nsw/nuw/fast-math flags as appropriate
58 #. Add noalias/align/dereferenceable/nonnull to function arguments and return
61 #. Mark functions as readnone/readonly/nounwind when known (especially for
64 #. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
65 analysis), prefer GEPs
67 #. Use the lifetime.start/lifetime.end and invariant.start/invariant.end
68 intrinsics where possible. Common profitable uses are for stack like data
69 structures (thus allowing dead store elimination) and for describing
70 life times of allocas (thus allowing smaller stack sizes).
72 #. Use pointer aliasing metadata, especially tbaa metadata, to communicate
73 otherwise-non-deducible pointer aliasing facts
75 #. Use the "most-private" possible linkage types for the functions being defined
76 (private, internal or linkonce_odr preferably)
78 #. Mark invariant locations using !invariant.load and TBAA's constant flags
80 #. Prefer globals over inttoptr of a constant address - this gives you
81 dereferencability information. In MCJIT, use getSymbolAddress to provide
84 #. Be wary of ordered and atomic memory operations. They are hard to optimize
85 and may not be well optimized by the current optimizer. Depending on your
86 source language, you may consider using fences instead.
88 #. If you language uses range checks, consider using the IRCE pass. It is not
89 currently part of the standard pass order.
91 p.s. If you want to help improve this document, patches expanding any of the
92 above items into standalone sections of their own with a more complete
93 discussion would be very welcome.
96 Adding to this document
97 =======================
99 If you run across a case that you feel deserves to be covered here, please send
100 a patch to `llvm-commits
101 <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_ for review.
103 If you have questions on these items, please direct them to `llvmdev
104 <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_. The more relevant
105 context you are able to give to your question, the more likely it is to be