docs/Frontend/PerformanceTips.rst

   1 =====================================
   2 Performance Tips for Frontend Authors
   3 =====================================
   4
   5 .. contents::
   6    :local:
   7    :depth: 2
   8
   9 Abstract
  10 ========
  11
  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.
  17
  18 Avoid loads and stores of large aggregate type
  19 ================================================
  20
  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.
  24
  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.
  28
  29 Prefer zext over sext when legal
  30 ==================================
  31
  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.
  37
  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.
  40
  41 Zext GEP indices to machine register width
  42 ============================================
  43
  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.
  49
  50 Other things to consider
  51 =========================
  52
  53 #. Make sure that a DataLayout is provided (this will likely become required in
  54    the near future, but is certainly important for optimization).
  55
  56 #. Add nsw/nuw/fast-math flags as appropriate
  57
  58 #. Add noalias/align/dereferenceable/nonnull to function arguments and return
  59    values as appropriate
  60
  61 #. Mark functions as readnone/readonly/nounwind when known (especially for
  62    external functions)
  63
  64 #. Use ptrtoint/inttoptr sparingly (they interfere with pointer aliasing
  65    analysis), prefer GEPs
  66
  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).
  71
  72 #. Use pointer aliasing metadata, especially tbaa metadata, to communicate
  73    otherwise-non-deducible pointer aliasing facts
  74
  75 #. Use the "most-private" possible linkage types for the functions being defined
  76    (private, internal or linkonce_odr preferably)
  77
  78 #. Mark invariant locations using !invariant.load and TBAA's constant flags
  79
  80 #. Prefer globals over inttoptr of a constant address - this gives you
  81    dereferencability information.  In MCJIT, use getSymbolAddress to provide
  82    actual address.
  83
  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.
  87
  88 #. If you language uses range checks, consider using the IRCE pass.  It is not
  89    currently part of the standard pass order.
  90
  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.
  94
  95
  96 Adding to this document
  97 =======================
  98
  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.
 102
 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
 106 answered.
 107