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

   1 //===-- README.txt - Notes for WebAssembly code gen -----------------------===//
   2
   3 This WebAssembly backend is presently in a very early stage of development.
   4 The code should build and not break anything else, but don't expect a lot more
   5 at this point.
   6
   7 For more information on WebAssembly itself, see the design documents:
   8   * https://github.com/WebAssembly/design/blob/master/README.md
   9
  10 The following documents contain some information on the planned semantics and
  11 binary encoding of WebAssembly itself:
  12   * https://github.com/WebAssembly/design/blob/master/AstSemantics.md
  13   * https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md
  14
  15 The backend is built, tested and archived on the following waterfall:
  16   https://wasm-stat.us
  17
  18 The backend's bringup is done using the GCC torture test suite first since it
  19 doesn't require C library support. Current known failures are in
  20 known_gcc_test_failures.txt, all other tests should pass. The waterfall will
  21 turn red if not. Once most of these pass, further testing will use LLVM's own
  22 test suite. The tests can be run locally using:
  23   https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py
  24
  25 //===---------------------------------------------------------------------===//
  26
  27 Br, br_if, and br_table instructions can support having a value on the
  28 expression stack across the jump (sometimes). We should (a) model this, and
  29 (b) extend the stackifier to utilize it.
  30
  31 //===---------------------------------------------------------------------===//
  32
  33 The min/max operators aren't exactly a<b?a:b because of NaN and negative zero
  34 behavior. The ARM target has the same kind of min/max instructions and has
  35 implemented optimizations for them; we should do similar optimizations for
  36 WebAssembly.
  37
  38 //===---------------------------------------------------------------------===//
  39
  40 AArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM.
  41 Would these be useful to run for WebAssembly too? Also, it has an option to
  42 run SimplifyCFG after running the AtomicExpand pass. Would this be useful for
  43 us too?
  44
  45 //===---------------------------------------------------------------------===//
  46
  47 Register stackification uses the EXPR_STACK physical register to impose
  48 ordering dependencies on instructions with stack operands. This is pessimistic;
  49 we should consider alternate ways to model stack dependencies.
  50
  51 //===---------------------------------------------------------------------===//
  52
  53 Lots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly,
  54 there are numerous optimization-related hooks that can be overridden in
  55 WebAssemblyTargetLowering.
  56
  57 //===---------------------------------------------------------------------===//
  58
  59 Instead of the OptimizeReturned pass, which should consider preserving the
  60 "returned" attribute through to MachineInstrs and extending the StoreResults
  61 pass to do this optimization on calls too. That would also let the
  62 WebAssemblyPeephole pass clean up dead defs for such calls, as it does for
  63 stores.
  64
  65 //===---------------------------------------------------------------------===//
  66
  67 Consider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch,
  68 optimizeLoadInstr, and/or getMachineCombinerPatterns.
  69
  70 //===---------------------------------------------------------------------===//
  71
  72 Find a clean way to fix the problem which leads to the Shrink Wrapping pass
  73 being run after the WebAssembly PEI pass.
  74
  75 //===---------------------------------------------------------------------===//
  76
  77 When setting multiple local variables to the same constant, we currently get
  78 code like this:
  79
  80     i32.const   $4=, 0
  81     i32.const   $3=, 0
  82
  83 It could be done with a smaller encoding like this:
  84
  85     i32.const   $push5=, 0
  86     tee_local   $push6=, $4=, $pop5
  87     copy_local  $3=, $pop6
  88
  89 //===---------------------------------------------------------------------===//
  90
  91 WebAssembly registers are implicitly initialized to zero. Explicit zeroing is
  92 therefore often redundant and could be optimized away.
  93
  94 //===---------------------------------------------------------------------===//
  95
  96 Small indices may use smaller encodings than large indices.
  97 WebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers
  98 according to their usage frequency to maximize the usage of smaller encodings.
  99
 100 //===---------------------------------------------------------------------===//
 101
 102 When the last statement in a function body computes the return value, it can
 103 just let that value be the exit value of the outermost block, rather than
 104 needing an explicit return operation.
 105
 106 //===---------------------------------------------------------------------===//
 107
 108 Many cases of irreducible control flow could be transformed more optimally
 109 than via the transform in WebAssemblyFixIrreducibleControlFlow.cpp.
 110
 111 It may also be worthwhile to do transforms before register coloring,
 112 particularly when duplicating code, to allow register coloring to be aware of
 113 the duplication.
 114
 115 //===---------------------------------------------------------------------===//
 116
 117 WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more
 118 aggressively.
 119
 120 //===---------------------------------------------------------------------===//
 121
 122 WebAssemblyRegStackify is currently a greedy algorithm. This means that, for
 123 example, a binary operator will stackify with its user before its operands.
 124 However, if moving the binary operator to its user moves it to a place where
 125 its operands can't be moved to, it would be better to leave it in place, or
 126 perhaps move it up, so that it can stackify its operands. A binary operator
 127 has two operands and one result, so in such cases there could be a net win by
 128 prefering the operands.
 129
 130 //===---------------------------------------------------------------------===//
 131
 132 Instruction ordering has a significant influence on register stackification and
 133 coloring. Consider experimenting with the MachineScheduler (enable via
 134 enableMachineScheduler) and determine if it can be configured to schedule
 135 instructions advantageously for this purpose.
 136
 137 //===---------------------------------------------------------------------===//