llvm.org GIT mirror llvm / b16dac5
[new docs] Performance Tips for Frontend Authors As mentioned on llvm-dev, this is a new documentation page intended to collect tips for frontend authors on how to generate IR that LLVM is able to optimize well. These types of things come up repeated in review threads and it would be good to have a place to save them. I added a small handful to start us off, but I mostly want to get the framework in place. Once the docs are here, we can add to them incrementally. If you know of something appropriate for this page, please add it! Differential Revision: http://reviews.llvm.org/D7890 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@230807 91177308-0d34-0410-b5e6-96231b3b80d8 Philip Reames 4 years ago
3 changed file(s) with 70 addition(s) and 0 deletion(s). Raw diff Collapse all Expand all
0 =====================================
1 Performance Tips for Frontend Authors
2 =====================================
3
4 .. contents::
5 :local:
6 :depth: 2
7
8 Abstract
9 ========
10
11 The intended audience of this document is developers of language frontends
12 targeting LLVM IR. This document is home to a collection of tips on how to
13 generate IR that optimizes well. As with any optimizer, LLVM has its strengths
14 and weaknesses. In some cases, surprisingly small changes in the source IR
15 can have a large effect on the generated code.
16
17 Avoid loads and stores of large aggregate type
18 ================================================
19
20 LLVM currently does not optimize well loads and stores of large :ref:`aggregate
21 types ` (i.e. structs and arrays). As an alternative, consider
22 loading individual fields from memory.
23
24 Aggregates that are smaller than the largest (performant) load or store
25 instruction supported by the targeted hardware are well supported. These can
26 be an effective way to represent collections of small packed fields.
27
28 Prefer zext over sext when legal
29 ==================================
30
31 On some architectures (X86_64 is one), sign extension can involve an extra
32 instruction whereas zero extension can be folded into a load. LLVM will try to
33 replace a sext with a zext when it can be proven safe, but if you have
34 information in your source language about the range of a integer value, it can
35 be profitable to use a zext rather than a sext.
36
37 Alternatively, you can :ref:`specify the range of the value using metadata
38 ` and LLVM can do the sext to zext conversion for you.
39
40 Zext GEP indices to machine register width
41 ============================================
42
43 Internally, LLVM often promotes the width of GEP indices to machine register
44 width. When it does so, it will default to using sign extension (sext)
45 operations for safety. If your source language provides information about
46 the range of the index, you may wish to manually extend indices to machine
47 register width using a zext instruction.
48
49
50 Adding to this document
51 =======================
52
53 If you run across a case that you feel deserves to be covered here, please send
54 a patch to `llvm-commits
55 `_ for review.
56
57 If you have questions on these items, please direct them to `llvmdev
58 `_. The more relevant
59 context you are able to give to your question, the more likely it is to be
60 answered.
61
30553055
30563056 !0 = !{ float 2.5 } ; maximum acceptable inaccuracy is 2.5 ULPs
30573057
3058 .. _range-metadata:
3059
30583060 '``range``' Metadata
30593061 ^^^^^^^^^^^^^^^^^^^^
30603062
8282 Passes
8383 YamlIO
8484 GetElementPtr
85 Frontend/PerformanceTips
8586 MCJITDesignAndImplementation
8687
8788 :doc:`GettingStarted`
148149 :doc:`GetElementPtr`
149150 Answers to some very frequent questions about LLVM's most frequently
150151 misunderstood instruction.
152
153 :doc:`Frontend/PerformanceTips`
154 A collection of tips for frontend authors on how to generate IR
155 which LLVM is able to effectively optimize.
156
151157
152158 Programming Documentation
153159 =========================