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