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