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.
51 Adding to this document
52 =======================
54 If you run across a case that you feel deserves to be covered here, please send
55 a patch to `llvm-commits
56 <http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits>`_ for review.
58 If you have questions on these items, please direct them to `llvmdev
59 <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev>`_. The more relevant
60 context you are able to give to your question, the more likely it is to be