contrib/llvm/lib/Target/WebAssembly/README.txt

   1 //===-- README.txt - Notes for WebAssembly code gen -----------------------===//
   2
   3 This WebAssembly backend is presently under development.
   4
   5 Currently the easiest way to use it is through Emscripten, which provides a
   6 compilation environment that includes standard libraries, tools, and packaging
   7 for producing WebAssembly applications that can run in browsers and other
   8 environments. For more information, see the Emscripten documentation in
   9 general, and this page in particular:
  10   * https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend
  11
  12 Other ways of using this backend, such as via a standalone "clang", are also
  13 under development, though they are not generally usable yet.
  14
  15 For more information on WebAssembly itself, see the home page:
  16   * https://webassembly.github.io/
  17
  18 The following documents contain some information on the semantics and binary
  19 encoding of WebAssembly itself:
  20   * https://github.com/WebAssembly/design/blob/master/Semantics.md
  21   * https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md
  22
  23 The backend is built, tested and archived on the following waterfall:
  24   https://wasm-stat.us
  25
  26 The backend's bringup is done in part by using the GCC torture test suite, since
  27 it doesn't require C library support. Current known failures are in
  28 known_gcc_test_failures.txt, all other tests should pass. The waterfall will
  29 turn red if not. Once most of these pass, further testing will use LLVM's own
  30 test suite. The tests can be run locally using:
  31   https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py
  32
  33 //===---------------------------------------------------------------------===//
  34
  35 Br, br_if, and br_table instructions can support having a value on the value
  36 stack across the jump (sometimes). We should (a) model this, and (b) extend
  37 the stackifier to utilize it.
  38
  39 //===---------------------------------------------------------------------===//
  40
  41 The min/max instructions aren't exactly a<b?a:b because of NaN and negative zero
  42 behavior. The ARM target has the same kind of min/max instructions and has
  43 implemented optimizations for them; we should do similar optimizations for
  44 WebAssembly.
  45
  46 //===---------------------------------------------------------------------===//
  47
  48 AArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM.
  49 Would these be useful to run for WebAssembly too? Also, it has an option to
  50 run SimplifyCFG after running the AtomicExpand pass. Would this be useful for
  51 us too?
  52
  53 //===---------------------------------------------------------------------===//
  54
  55 Register stackification uses the VALUE_STACK physical register to impose
  56 ordering dependencies on instructions with stack operands. This is pessimistic;
  57 we should consider alternate ways to model stack dependencies.
  58
  59 //===---------------------------------------------------------------------===//
  60
  61 Lots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly,
  62 there are numerous optimization-related hooks that can be overridden in
  63 WebAssemblyTargetLowering.
  64
  65 //===---------------------------------------------------------------------===//
  66
  67 Instead of the OptimizeReturned pass, which should consider preserving the
  68 "returned" attribute through to MachineInstrs and extending the StoreResults
  69 pass to do this optimization on calls too. That would also let the
  70 WebAssemblyPeephole pass clean up dead defs for such calls, as it does for
  71 stores.
  72
  73 //===---------------------------------------------------------------------===//
  74
  75 Consider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch,
  76 optimizeLoadInstr, and/or getMachineCombinerPatterns.
  77
  78 //===---------------------------------------------------------------------===//
  79
  80 Find a clean way to fix the problem which leads to the Shrink Wrapping pass
  81 being run after the WebAssembly PEI pass.
  82
  83 //===---------------------------------------------------------------------===//
  84
  85 When setting multiple local variables to the same constant, we currently get
  86 code like this:
  87
  88     i32.const   $4=, 0
  89     i32.const   $3=, 0
  90
  91 It could be done with a smaller encoding like this:
  92
  93     i32.const   $push5=, 0
  94     tee_local   $push6=, $4=, $pop5
  95     copy_local  $3=, $pop6
  96
  97 //===---------------------------------------------------------------------===//
  98
  99 WebAssembly registers are implicitly initialized to zero. Explicit zeroing is
 100 therefore often redundant and could be optimized away.
 101
 102 //===---------------------------------------------------------------------===//
 103
 104 Small indices may use smaller encodings than large indices.
 105 WebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers
 106 according to their usage frequency to maximize the usage of smaller encodings.
 107
 108 //===---------------------------------------------------------------------===//
 109
 110 Many cases of irreducible control flow could be transformed more optimally
 111 than via the transform in WebAssemblyFixIrreducibleControlFlow.cpp.
 112
 113 It may also be worthwhile to do transforms before register coloring,
 114 particularly when duplicating code, to allow register coloring to be aware of
 115 the duplication.
 116
 117 //===---------------------------------------------------------------------===//
 118
 119 WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more
 120 aggressively.
 121
 122 //===---------------------------------------------------------------------===//
 123
 124 WebAssemblyRegStackify is currently a greedy algorithm. This means that, for
 125 example, a binary operator will stackify with its user before its operands.
 126 However, if moving the binary operator to its user moves it to a place where
 127 its operands can't be moved to, it would be better to leave it in place, or
 128 perhaps move it up, so that it can stackify its operands. A binary operator
 129 has two operands and one result, so in such cases there could be a net win by
 130 prefering the operands.
 131
 132 //===---------------------------------------------------------------------===//
 133
 134 Instruction ordering has a significant influence on register stackification and
 135 coloring. Consider experimenting with the MachineScheduler (enable via
 136 enableMachineScheduler) and determine if it can be configured to schedule
 137 instructions advantageously for this purpose.
 138
 139 //===---------------------------------------------------------------------===//
 140
 141 WebAssembly is now officially a stack machine, rather than an AST, and this
 142 comes with additional opportunities for WebAssemblyRegStackify. Specifically,
 143 the stack doesn't need to be empty after an instruction with no return values.
 144 WebAssemblyRegStackify could be extended, or possibly rewritten, to take
 145 advantage of the new opportunities.
 146
 147 //===---------------------------------------------------------------------===//
 148
 149 Add support for mergeable sections in the Wasm writer, such as for strings and
 150 floating-point constants.
 151
 152 //===---------------------------------------------------------------------===//
 153
 154 The function @dynamic_alloca_redzone in test/CodeGen/WebAssembly/userstack.ll
 155 ends up with a tee_local in its prolog which has an unused result, requiring
 156 an extra drop:
 157
 158     get_global  $push8=, 0
 159     tee_local   $push9=, 1, $pop8
 160     drop        $pop9
 161     [...]
 162
 163 The prologue code initially thinks it needs an FP register, but later it
 164 turns out to be unneeded, so one could either approach this by being more
 165 clever about not inserting code for an FP in the first place, or optimizing
 166 away the copy later.
 167
 168 //===---------------------------------------------------------------------===//