1//===-- README.txt - Notes for WebAssembly code gen -----------------------===// 2 3This WebAssembly backend is presently under development. 4 5The most notable feature which is not yet stable is the ".o" file format. 6".o" file support is needed for many common ways of using LLVM, such as 7using it through "clang -c", so this backend is not yet considered widely 8usable. However, this backend is usable within some language toolchain 9packages: 10 11Emscripten provides a C/C++ compilation environment that includes standard 12libraries, tools, and packaging for producing WebAssembly applications that 13can run in browsers and other environments. For more information, see the 14Emscripten documentation in general, and this page in particular: 15 16 * https://github.com/kripken/emscripten/wiki/New-WebAssembly-Backend 17 18Rust provides WebAssembly support integrated into Cargo. There are two 19main options: 20 - wasm32-unknown-unknown, which provides a relatively minimal environment 21 that has an emphasis on being "native" 22 - wasm32-unknown-emscripten, which uses Emscripten internally and 23 provides standard C/C++ libraries, filesystem emulation, GL and SDL 24 bindings 25For more information, see: 26 * https://www.hellorust.com/ 27 28 29This backend does not yet support debug info. Full DWARF support needs a 30design for how DWARF should be represented in WebAssembly. Sourcemap support 31has an existing design and some corresponding browser implementations, so it 32just needs implementing in LLVM. 33 34Work-in-progress documentation for the ".o" file format is here: 35 36 * https://github.com/WebAssembly/tool-conventions/blob/master/Linking.md 37 38A corresponding linker implementation is also under development: 39 40 * https://lld.llvm.org/WebAssembly.html 41 42For more information on WebAssembly itself, see the home page: 43 * https://webassembly.github.io/ 44 45The following documents contain some information on the semantics and binary 46encoding of WebAssembly itself: 47 * https://github.com/WebAssembly/design/blob/master/Semantics.md 48 * https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md 49 50The backend is built, tested and archived on the following waterfall: 51 https://wasm-stat.us 52 53The backend's bringup is done in part by using the GCC torture test suite, since 54it doesn't require C library support. Current known failures are in 55known_gcc_test_failures.txt, all other tests should pass. The waterfall will 56turn red if not. Once most of these pass, further testing will use LLVM's own 57test suite. The tests can be run locally using: 58 https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py 59 60Some notes on ways that the generated code could be improved follow: 61 62//===---------------------------------------------------------------------===// 63 64Br, br_if, and br_table instructions can support having a value on the value 65stack across the jump (sometimes). We should (a) model this, and (b) extend 66the stackifier to utilize it. 67 68//===---------------------------------------------------------------------===// 69 70The min/max instructions aren't exactly a<b?a:b because of NaN and negative zero 71behavior. The ARM target has the same kind of min/max instructions and has 72implemented optimizations for them; we should do similar optimizations for 73WebAssembly. 74 75//===---------------------------------------------------------------------===// 76 77AArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM. 78Would these be useful to run for WebAssembly too? Also, it has an option to 79run SimplifyCFG after running the AtomicExpand pass. Would this be useful for 80us too? 81 82//===---------------------------------------------------------------------===// 83 84Register stackification uses the VALUE_STACK physical register to impose 85ordering dependencies on instructions with stack operands. This is pessimistic; 86we should consider alternate ways to model stack dependencies. 87 88//===---------------------------------------------------------------------===// 89 90Lots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly, 91there are numerous optimization-related hooks that can be overridden in 92WebAssemblyTargetLowering. 93 94//===---------------------------------------------------------------------===// 95 96Instead of the OptimizeReturned pass, which should consider preserving the 97"returned" attribute through to MachineInstrs and extending the 98MemIntrinsicResults pass to do this optimization on calls too. That would also 99let the WebAssemblyPeephole pass clean up dead defs for such calls, as it does 100for stores. 101 102//===---------------------------------------------------------------------===// 103 104Consider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch, 105optimizeLoadInstr, and/or getMachineCombinerPatterns. 106 107//===---------------------------------------------------------------------===// 108 109Find a clean way to fix the problem which leads to the Shrink Wrapping pass 110being run after the WebAssembly PEI pass. 111 112//===---------------------------------------------------------------------===// 113 114When setting multiple local variables to the same constant, we currently get 115code like this: 116 117 i32.const $4=, 0 118 i32.const $3=, 0 119 120It could be done with a smaller encoding like this: 121 122 i32.const $push5=, 0 123 local.tee $push6=, $4=, $pop5 124 local.copy $3=, $pop6 125 126//===---------------------------------------------------------------------===// 127 128WebAssembly registers are implicitly initialized to zero. Explicit zeroing is 129therefore often redundant and could be optimized away. 130 131//===---------------------------------------------------------------------===// 132 133Small indices may use smaller encodings than large indices. 134WebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers 135according to their usage frequency to maximize the usage of smaller encodings. 136 137//===---------------------------------------------------------------------===// 138 139Many cases of irreducible control flow could be transformed more optimally 140than via the transform in WebAssemblyFixIrreducibleControlFlow.cpp. 141 142It may also be worthwhile to do transforms before register coloring, 143particularly when duplicating code, to allow register coloring to be aware of 144the duplication. 145 146//===---------------------------------------------------------------------===// 147 148WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more 149aggressively. 150 151//===---------------------------------------------------------------------===// 152 153WebAssemblyRegStackify is currently a greedy algorithm. This means that, for 154example, a binary operator will stackify with its user before its operands. 155However, if moving the binary operator to its user moves it to a place where 156its operands can't be moved to, it would be better to leave it in place, or 157perhaps move it up, so that it can stackify its operands. A binary operator 158has two operands and one result, so in such cases there could be a net win by 159preferring the operands. 160 161//===---------------------------------------------------------------------===// 162 163Instruction ordering has a significant influence on register stackification and 164coloring. Consider experimenting with the MachineScheduler (enable via 165enableMachineScheduler) and determine if it can be configured to schedule 166instructions advantageously for this purpose. 167 168//===---------------------------------------------------------------------===// 169 170WebAssemblyRegStackify currently assumes that the stack must be empty after 171an instruction with no return values, however wasm doesn't actually require 172this. WebAssemblyRegStackify could be extended, or possibly rewritten, to take 173full advantage of what WebAssembly permits. 174 175//===---------------------------------------------------------------------===// 176 177Add support for mergeable sections in the Wasm writer, such as for strings and 178floating-point constants. 179 180//===---------------------------------------------------------------------===// 181 182The function @dynamic_alloca_redzone in test/CodeGen/WebAssembly/userstack.ll 183ends up with a local.tee in its prolog which has an unused result, requiring 184an extra drop: 185 186 global.get $push8=, 0 187 local.tee $push9=, 1, $pop8 188 drop $pop9 189 [...] 190 191The prologue code initially thinks it needs an FP register, but later it 192turns out to be unneeded, so one could either approach this by being more 193clever about not inserting code for an FP in the first place, or optimizing 194away the copy later. 195 196//===---------------------------------------------------------------------===// 197