brintos

brintos / llvm-project-archived public Read only

0
0
Text · 7.2 KiB · 8dc2d7f Raw
174 lines · plain
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.md6 7The C ABI is described in:8 9  * https://github.com/WebAssembly/tool-conventions/blob/main/BasicCABI.md10 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 which16includes standard libraries, tools, and packaging for producing WebAssembly17applications 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 based20on musl, for producing WebAssembly applications that use the WASI ABI.21 22Rust provides WebAssembly support integrated into Cargo. There are two23main options:24 - wasm32-unknown-unknown, which provides a relatively minimal environment25   that has an emphasis on being "native"26 - wasm32-unknown-emscripten, which uses Emscripten internally and27   provides standard C/C++ libraries, filesystem emulation, GL and SDL28   bindings29For more information, see:30  * https://www.hellorust.com/31 32The following documents contain some information on the semantics and binary33encoding of WebAssembly itself:34  * https://github.com/WebAssembly/design/blob/main/Semantics.md35  * https://github.com/WebAssembly/design/blob/main/BinaryEncoding.md36 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 value42stack across the jump (sometimes). We should (a) model this, and (b) extend43the stackifier to utilize it.44 45//===---------------------------------------------------------------------===//46 47The min/max instructions aren't exactly a<b?a:b because of NaN and negative zero48behavior. The ARM target has the same kind of min/max instructions and has49implemented optimizations for them; we should do similar optimizations for50WebAssembly.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 to56run SimplifyCFG after running the AtomicExpand pass. Would this be useful for57us too?58 59//===---------------------------------------------------------------------===//60 61Register stackification uses the VALUE_STACK physical register to impose62ordering 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 in69WebAssemblyTargetLowering.70 71//===---------------------------------------------------------------------===//72 73Instead of the OptimizeReturned pass, which should consider preserving the74"returned" attribute through to MachineInstrs and extending the75MemIntrinsicResults pass to do this optimization on calls too. That would also76let the WebAssemblyPeephole pass clean up dead defs for such calls, as it does77for 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 pass87being run after the WebAssembly PEI pass.88 89//===---------------------------------------------------------------------===//90 91When setting multiple local variables to the same constant, we currently get92code like this:93 94    i32.const   $4=, 095    i32.const   $3=, 096 97It could be done with a smaller encoding like this:98 99    i32.const   $push5=, 0100    local.tee   $push6=, $4=, $pop5101    local.copy  $3=, $pop6102 103//===---------------------------------------------------------------------===//104 105WebAssembly registers are implicitly initialized to zero. Explicit zeroing is106therefore 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 registers112according to their usage frequency to maximize the usage of smaller encodings.113 114//===---------------------------------------------------------------------===//115 116Many cases of irreducible control flow could be transformed more optimally117than 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 of121the duplication.122 123//===---------------------------------------------------------------------===//124 125WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more126aggressively.127 128//===---------------------------------------------------------------------===//129 130WebAssemblyRegStackify is currently a greedy algorithm. This means that, for131example, 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 where133its operands can't be moved to, it would be better to leave it in place, or134perhaps move it up, so that it can stackify its operands. A binary operator135has two operands and one result, so in such cases there could be a net win by136preferring the operands.137 138//===---------------------------------------------------------------------===//139 140Instruction ordering has a significant influence on register stackification and141coloring. Consider experimenting with the MachineScheduler (enable via142enableMachineScheduler) and determine if it can be configured to schedule143instructions advantageously for this purpose.144 145//===---------------------------------------------------------------------===//146 147WebAssemblyRegStackify currently assumes that the stack must be empty after148an instruction with no return values, however wasm doesn't actually require149this. WebAssemblyRegStackify could be extended, or possibly rewritten, to take150full advantage of what WebAssembly permits.151 152//===---------------------------------------------------------------------===//153 154Add support for mergeable sections in the Wasm writer, such as for strings and155floating-point constants.156 157//===---------------------------------------------------------------------===//158 159The function @dynamic_alloca_redzone in test/CodeGen/WebAssembly/userstack.ll160ends up with a local.tee in its prolog which has an unused result, requiring161an extra drop:162 163    global.get  $push8=, 0164    local.tee   $push9=, 1, $pop8165    drop        $pop9166    [...]167 168The prologue code initially thinks it needs an FP register, but later it169turns out to be unneeded, so one could either approach this by being more170clever about not inserting code for an FP in the first place, or optimizing171away the copy later.172 173//===---------------------------------------------------------------------===//174