1//===-- README.txt - Notes for WebAssembly code gen -----------------------===//
2
3This WebAssembly backend is presently in a very early stage of development.
4The code should build and not break anything else, but don't expect a lot more
5at this point.
6
7For more information on WebAssembly itself, see the design documents:
8  * https://github.com/WebAssembly/design/blob/master/README.md
9
10The following documents contain some information on the planned semantics and
11binary 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
15The backend is built, tested and archived on the following waterfall:
16  https://wasm-stat.us
17
18The backend's bringup is done using the GCC torture test suite first since it
19doesn't require C library support. Current known failures are in
20known_gcc_test_failures.txt, all other tests should pass. The waterfall will
21turn red if not. Once most of these pass, further testing will use LLVM's own
22test suite. The tests can be run locally using:
23  https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py
24
25Interesting 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
35Br, br_if, and tableswitch instructions can support having a value on the
36expression stack across the jump (sometimes). We should (a) model this, and
37(b) extend the stackifier to utilize it.
38
39//===---------------------------------------------------------------------===//
40
41The min/max operators aren't exactly a<b?a:b because of NaN and negative zero
42behavior. The ARM target has the same kind of min/max instructions and has
43implemented optimizations for them; we should do similar optimizations for
44WebAssembly.
45
46//===---------------------------------------------------------------------===//
47
48AArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM.
49Would these be useful to run for WebAssembly too? Also, it has an option to
50run SimplifyCFG after running the AtomicExpand pass. Would this be useful for
51us too?
52
53//===---------------------------------------------------------------------===//
54
55Register stackification uses the EXPR_STACK physical register to impose
56ordering dependencies on instructions with stack operands. This is pessimistic;
57we should consider alternate ways to model stack dependencies.
58
59//===---------------------------------------------------------------------===//
60
61Lots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly,
62there are numerous optimization-related hooks that can be overridden in
63WebAssemblyTargetLowering.
64
65//===---------------------------------------------------------------------===//
66
67Instead of the OptimizeReturned pass, which should consider preserving the
68"returned" attribute through to MachineInstrs and extending the StoreResults
69pass to do this optimization on calls too. That would also let the
70WebAssemblyPeephole pass clean up dead defs for such calls, as it does for
71stores.
72
73//===---------------------------------------------------------------------===//
74
75Consider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch,
76optimizeLoadInstr, and/or getMachineCombinerPatterns.
77
78//===---------------------------------------------------------------------===//
79
80Find a clean way to fix the problem which leads to the Shrink Wrapping pass
81being run after the WebAssembly PEI pass.
82
83//===---------------------------------------------------------------------===//
84
85When setting multiple local variables to the same constant, we currently get
86code like this:
87
88    i32.const   $4=, 0
89    i32.const   $3=, 0
90
91It 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
99WebAssembly registers are implicitly initialized to zero. Explicit zeroing is
100therefore often redundant and could be optimized away.
101
102//===---------------------------------------------------------------------===//
103
104Small indices may use smaller encodings than large indices.
105WebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers
106according to their usage frequency to maximize the usage of smaller encodings.
107
108//===---------------------------------------------------------------------===//
109