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://build.chromium.org/p/client.wasm.llvm/console
  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   github.com/WebAssembly/experimental/blob/master/buildbot/torture_test.py
  24
  25 Interesting work that remains to be done:
  26 * Write a pass to restructurize irreducible control flow. This needs to be done
  27   before register allocation to be efficient, because it may duplicate basic
  28   blocks and WebAssembly performs register allocation at a whole-function
  29   level. Note that LLVM's GPU code has such a pass, but it linearizes control
  30   flow (e.g. both sides of branches execute and are masked) which is undesirable
  31   for WebAssembly.
  32
  33 //===---------------------------------------------------------------------===//
  34
  35 set_local instructions have a return value. We should (a) model this,
  36 and (b) write optimizations which take advantage of it. Keep in mind that
  37 many set_local instructions are implicit!
  38
  39 //===---------------------------------------------------------------------===//
  40
  41 Br, br_if, and tableswitch instructions can support having a value on the
  42 expression stack across the jump (sometimes). We should (a) model this, and
  43 (b) extend the stackifier to utilize it.
  44
  45 //===---------------------------------------------------------------------===//
  46
  47 The min/max operators aren't exactly a<b?a:b because of NaN and negative zero
  48 behavior. The ARM target has the same kind of min/max instructions and has
  49 implemented optimizations for them; we should do similar optimizations for
  50 WebAssembly.
  51
  52 //===---------------------------------------------------------------------===//
  53
  54 AArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM.
  55 Would these be useful to run for WebAssembly too? Also, it has an option to
  56 run SimplifyCFG after running the AtomicExpand pass. Would this be useful for
  57 us too?
  58
  59 //===---------------------------------------------------------------------===//
  60
  61 When is it profitable to set isAsCheapAsAMove on instructions in WebAssembly?
  62
  63 //===---------------------------------------------------------------------===//
  64
  65 Register stackification uses the EXPR_STACK physical register to impose
  66 ordering dependencies on instructions with stack operands. This is pessimistic;
  67 we should consider alternate ways to model stack dependencies.
  68
  69 //===---------------------------------------------------------------------===//
  70
  71 Lots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly,
  72 there are numerous optimization-related hooks that can be overridden in
  73 WebAssemblyTargetLowering.
  74
  75 //===---------------------------------------------------------------------===//
  76
  77 Instead of the OptimizeReturned pass, which should consider preserving the
  78 "returned" attribute through to MachineInstrs and extending the StoreResults
  79 pass to do this optimization on calls too. That would also let the
  80 WebAssemblyPeephole pass clean up dead defs for such calls, as it does for
  81 stores.
  82
  83 //===---------------------------------------------------------------------===//
  84
  85 Memset/memcpy/memmove should be marked with the "returned" attribute somehow,
  86 even when they are translated through intrinsics.
  87
  88 //===---------------------------------------------------------------------===//