README.txt revision 314564
1//===-- README.txt - Notes for WebAssembly code gen -----------------------===// 2 3This WebAssembly backend is presently under development. 4 5Currently the easiest way to use it is through Emscripten, which provides a 6compilation environment that includes standard libraries, tools, and packaging 7for producing WebAssembly applications that can run in browsers and other 8environments. For more information, see the Emscripten documentation in 9general, and this page in particular: 10 * https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend 11 12Other ways of using this backend, such as via a standalone "clang", are also 13under development, though they are not generally usable yet. 14 15For more information on WebAssembly itself, see the home page: 16 * https://webassembly.github.io/ 17 18The following documents contain some information on the semantics and binary 19encoding of WebAssembly itself: 20 * https://github.com/WebAssembly/design/blob/master/Semantics.md 21 * https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md 22 23The backend is built, tested and archived on the following waterfall: 24 https://wasm-stat.us 25 26The backend's bringup is done in part by using the GCC torture test suite, since 27it doesn't require C library support. Current known failures are in 28known_gcc_test_failures.txt, all other tests should pass. The waterfall will 29turn red if not. Once most of these pass, further testing will use LLVM's own 30test suite. The tests can be run locally using: 31 https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py 32 33//===---------------------------------------------------------------------===// 34 35Br, br_if, and br_table instructions can support having a value on the value 36stack across the jump (sometimes). We should (a) model this, and (b) extend 37the stackifier to utilize it. 38 39//===---------------------------------------------------------------------===// 40 41The min/max instructions 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 VALUE_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 110Many cases of irreducible control flow could be transformed more optimally 111than via the transform in WebAssemblyFixIrreducibleControlFlow.cpp. 112 113It may also be worthwhile to do transforms before register coloring, 114particularly when duplicating code, to allow register coloring to be aware of 115the duplication. 116 117//===---------------------------------------------------------------------===// 118 119WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more 120aggressively. 121 122//===---------------------------------------------------------------------===// 123 124WebAssemblyRegStackify is currently a greedy algorithm. This means that, for 125example, a binary operator will stackify with its user before its operands. 126However, if moving the binary operator to its user moves it to a place where 127its operands can't be moved to, it would be better to leave it in place, or 128perhaps move it up, so that it can stackify its operands. A binary operator 129has two operands and one result, so in such cases there could be a net win by 130prefering the operands. 131 132//===---------------------------------------------------------------------===// 133 134Instruction ordering has a significant influence on register stackification and 135coloring. Consider experimenting with the MachineScheduler (enable via 136enableMachineScheduler) and determine if it can be configured to schedule 137instructions advantageously for this purpose. 138 139//===---------------------------------------------------------------------===// 140 141WebAssembly is now officially a stack machine, rather than an AST, and this 142comes with additional opportunities for WebAssemblyRegStackify. Specifically, 143the stack doesn't need to be empty after an instruction with no return values. 144WebAssemblyRegStackify could be extended, or possibly rewritten, to take 145advantage of the new opportunities. 146 147//===---------------------------------------------------------------------===// 148