diff options
Diffstat (limited to 'lib/Target/WebAssembly/README.txt')
| -rw-r--r-- | lib/Target/WebAssembly/README.txt | 95 |
1 files changed, 72 insertions, 23 deletions
diff --git a/lib/Target/WebAssembly/README.txt b/lib/Target/WebAssembly/README.txt index b97ea454165c..a6c2eefc0578 100644 --- a/lib/Target/WebAssembly/README.txt +++ b/lib/Target/WebAssembly/README.txt @@ -13,32 +13,18 @@ binary encoding of WebAssembly itself: * https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md The backend is built, tested and archived on the following waterfall: - https://build.chromium.org/p/client.wasm.llvm/console + https://wasm-stat.us The backend's bringup is done using the GCC torture test suite first since it doesn't require C library support. Current known failures are in known_gcc_test_failures.txt, all other tests should pass. The waterfall will turn red if not. Once most of these pass, further testing will use LLVM's own test suite. The tests can be run locally using: - github.com/WebAssembly/experimental/blob/master/buildbot/torture_test.py - -Interesting work that remains to be done: -* Write a pass to restructurize irreducible control flow. This needs to be done - before register allocation to be efficient, because it may duplicate basic - blocks and WebAssembly performs register allocation at a whole-function - level. Note that LLVM's GPU code has such a pass, but it linearizes control - flow (e.g. both sides of branches execute and are masked) which is undesirable - for WebAssembly. + https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py //===---------------------------------------------------------------------===// -set_local instructions have a return value. We should (a) model this, -and (b) write optimizations which take advantage of it. Keep in mind that -many set_local instructions are implicit! - -//===---------------------------------------------------------------------===// - -Br, br_if, and tableswitch instructions can support having a value on the +Br, br_if, and br_table instructions can support having a value on the expression stack across the jump (sometimes). We should (a) model this, and (b) extend the stackifier to utilize it. @@ -58,10 +44,6 @@ us too? //===---------------------------------------------------------------------===// -When is it profitable to set isAsCheapAsAMove on instructions in WebAssembly? - -//===---------------------------------------------------------------------===// - Register stackification uses the EXPR_STACK physical register to impose ordering dependencies on instructions with stack operands. This is pessimistic; we should consider alternate ways to model stack dependencies. @@ -82,7 +64,74 @@ stores. //===---------------------------------------------------------------------===// -Memset/memcpy/memmove should be marked with the "returned" attribute somehow, -even when they are translated through intrinsics. +Consider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch, +optimizeLoadInstr, and/or getMachineCombinerPatterns. + +//===---------------------------------------------------------------------===// + +Find a clean way to fix the problem which leads to the Shrink Wrapping pass +being run after the WebAssembly PEI pass. + +//===---------------------------------------------------------------------===// + +When setting multiple local variables to the same constant, we currently get +code like this: + + i32.const $4=, 0 + i32.const $3=, 0 + +It could be done with a smaller encoding like this: + + i32.const $push5=, 0 + tee_local $push6=, $4=, $pop5 + copy_local $3=, $pop6 + +//===---------------------------------------------------------------------===// + +WebAssembly registers are implicitly initialized to zero. Explicit zeroing is +therefore often redundant and could be optimized away. + +//===---------------------------------------------------------------------===// + +Small indices may use smaller encodings than large indices. +WebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers +according to their usage frequency to maximize the usage of smaller encodings. + +//===---------------------------------------------------------------------===// + +When the last statement in a function body computes the return value, it can +just let that value be the exit value of the outermost block, rather than +needing an explicit return operation. + +//===---------------------------------------------------------------------===// + +Many cases of irreducible control flow could be transformed more optimally +than via the transform in WebAssemblyFixIrreducibleControlFlow.cpp. + +It may also be worthwhile to do transforms before register coloring, +particularly when duplicating code, to allow register coloring to be aware of +the duplication. + +//===---------------------------------------------------------------------===// + +WebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more +aggressively. + +//===---------------------------------------------------------------------===// + +WebAssemblyRegStackify is currently a greedy algorithm. This means that, for +example, a binary operator will stackify with its user before its operands. +However, if moving the binary operator to its user moves it to a place where +its operands can't be moved to, it would be better to leave it in place, or +perhaps move it up, so that it can stackify its operands. A binary operator +has two operands and one result, so in such cases there could be a net win by +prefering the operands. + +//===---------------------------------------------------------------------===// + +Instruction ordering has a significant influence on register stackification and +coloring. Consider experimenting with the MachineScheduler (enable via +enableMachineScheduler) and determine if it can be configured to schedule +instructions advantageously for this purpose. //===---------------------------------------------------------------------===// |