README.txt revision 309124 
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
25//===---------------------------------------------------------------------===//
26
27Br, br_if, and br_table instructions can support having a value on the
28expression stack across the jump (sometimes). We should (a) model this, and
29(b) extend the stackifier to utilize it.
30
31//===---------------------------------------------------------------------===//
32
33The min/max operators aren't exactly a<b?a:b because of NaN and negative zero
34behavior. The ARM target has the same kind of min/max instructions and has
35implemented optimizations for them; we should do similar optimizations for
36WebAssembly.
37
38//===---------------------------------------------------------------------===//
39
40AArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM.
41Would these be useful to run for WebAssembly too? Also, it has an option to
42run SimplifyCFG after running the AtomicExpand pass. Would this be useful for
43us too?
44
45//===---------------------------------------------------------------------===//
46
47Register stackification uses the EXPR_STACK physical register to impose
48ordering dependencies on instructions with stack operands. This is pessimistic;
49we should consider alternate ways to model stack dependencies.
50
51//===---------------------------------------------------------------------===//
52
53Lots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly,
54there are numerous optimization-related hooks that can be overridden in
55WebAssemblyTargetLowering.
56
57//===---------------------------------------------------------------------===//
58
59Instead of the OptimizeReturned pass, which should consider preserving the
60"returned" attribute through to MachineInstrs and extending the StoreResults
61pass to do this optimization on calls too. That would also let the
62WebAssemblyPeephole pass clean up dead defs for such calls, as it does for
63stores.
64
65//===---------------------------------------------------------------------===//
66
67Consider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch,
68optimizeLoadInstr, and/or getMachineCombinerPatterns.
69
70//===---------------------------------------------------------------------===//
71
72Find a clean way to fix the problem which leads to the Shrink Wrapping pass
73being run after the WebAssembly PEI pass.
74
75//===---------------------------------------------------------------------===//
76
77When setting multiple local variables to the same constant, we currently get
78code like this:
79
80    i32.const   $4=, 0
81    i32.const   $3=, 0
82
83It 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
91WebAssembly registers are implicitly initialized to zero. Explicit zeroing is
92therefore often redundant and could be optimized away.
93
94//===---------------------------------------------------------------------===//
95
96Small indices may use smaller encodings than large indices.
97WebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers
98according to their usage frequency to maximize the usage of smaller encodings.
99
100//===---------------------------------------------------------------------===//
101
102When the last statement in a function body computes the return value, it can
103just let that value be the exit value of the outermost block, rather than
104needing an explicit return operation.
105
106//===---------------------------------------------------------------------===//
107
108Many cases of irreducible control flow could be transformed more optimally
109than via the transform in WebAssemblyFixIrreducibleControlFlow.cpp.
110
111It may also be worthwhile to do transforms before register coloring,
112particularly when duplicating code, to allow register coloring to be aware of
113the duplication.
114
115//===---------------------------------------------------------------------===//
116
117WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more
118aggressively.
119
120//===---------------------------------------------------------------------===//
121
122WebAssemblyRegStackify is currently a greedy algorithm. This means that, for
123example, a binary operator will stackify with its user before its operands.
124However, if moving the binary operator to its user moves it to a place where
125its operands can't be moved to, it would be better to leave it in place, or
126perhaps move it up, so that it can stackify its operands. A binary operator
127has two operands and one result, so in such cases there could be a net win by
128prefering the operands.
129
130//===---------------------------------------------------------------------===//
131
132Instruction ordering has a significant influence on register stackification and
133coloring. Consider experimenting with the MachineScheduler (enable via
134enableMachineScheduler) and determine if it can be configured to schedule
135instructions advantageously for this purpose.
136
137//===---------------------------------------------------------------------===//
138