1*9880d681SAndroid Build Coastguard Worker//===-- README.txt - Notes for WebAssembly code gen -----------------------===// 2*9880d681SAndroid Build Coastguard Worker 3*9880d681SAndroid Build Coastguard WorkerThis WebAssembly backend is presently in a very early stage of development. 4*9880d681SAndroid Build Coastguard WorkerThe code should build and not break anything else, but don't expect a lot more 5*9880d681SAndroid Build Coastguard Workerat this point. 6*9880d681SAndroid Build Coastguard Worker 7*9880d681SAndroid Build Coastguard WorkerFor more information on WebAssembly itself, see the design documents: 8*9880d681SAndroid Build Coastguard Worker * https://github.com/WebAssembly/design/blob/master/README.md 9*9880d681SAndroid Build Coastguard Worker 10*9880d681SAndroid Build Coastguard WorkerThe following documents contain some information on the planned semantics and 11*9880d681SAndroid Build Coastguard Workerbinary encoding of WebAssembly itself: 12*9880d681SAndroid Build Coastguard Worker * https://github.com/WebAssembly/design/blob/master/AstSemantics.md 13*9880d681SAndroid Build Coastguard Worker * https://github.com/WebAssembly/design/blob/master/BinaryEncoding.md 14*9880d681SAndroid Build Coastguard Worker 15*9880d681SAndroid Build Coastguard WorkerThe backend is built, tested and archived on the following waterfall: 16*9880d681SAndroid Build Coastguard Worker https://wasm-stat.us 17*9880d681SAndroid Build Coastguard Worker 18*9880d681SAndroid Build Coastguard WorkerThe backend's bringup is done using the GCC torture test suite first since it 19*9880d681SAndroid Build Coastguard Workerdoesn't require C library support. Current known failures are in 20*9880d681SAndroid Build Coastguard Workerknown_gcc_test_failures.txt, all other tests should pass. The waterfall will 21*9880d681SAndroid Build Coastguard Workerturn red if not. Once most of these pass, further testing will use LLVM's own 22*9880d681SAndroid Build Coastguard Workertest suite. The tests can be run locally using: 23*9880d681SAndroid Build Coastguard Worker https://github.com/WebAssembly/waterfall/blob/master/src/compile_torture_tests.py 24*9880d681SAndroid Build Coastguard Worker 25*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 26*9880d681SAndroid Build Coastguard Worker 27*9880d681SAndroid Build Coastguard WorkerBr, br_if, and br_table instructions can support having a value on the 28*9880d681SAndroid Build Coastguard Workerexpression stack across the jump (sometimes). We should (a) model this, and 29*9880d681SAndroid Build Coastguard Worker(b) extend the stackifier to utilize it. 30*9880d681SAndroid Build Coastguard Worker 31*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 32*9880d681SAndroid Build Coastguard Worker 33*9880d681SAndroid Build Coastguard WorkerThe min/max operators aren't exactly a<b?a:b because of NaN and negative zero 34*9880d681SAndroid Build Coastguard Workerbehavior. The ARM target has the same kind of min/max instructions and has 35*9880d681SAndroid Build Coastguard Workerimplemented optimizations for them; we should do similar optimizations for 36*9880d681SAndroid Build Coastguard WorkerWebAssembly. 37*9880d681SAndroid Build Coastguard Worker 38*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 39*9880d681SAndroid Build Coastguard Worker 40*9880d681SAndroid Build Coastguard WorkerAArch64 runs SeparateConstOffsetFromGEPPass, followed by EarlyCSE and LICM. 41*9880d681SAndroid Build Coastguard WorkerWould these be useful to run for WebAssembly too? Also, it has an option to 42*9880d681SAndroid Build Coastguard Workerrun SimplifyCFG after running the AtomicExpand pass. Would this be useful for 43*9880d681SAndroid Build Coastguard Workerus too? 44*9880d681SAndroid Build Coastguard Worker 45*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 46*9880d681SAndroid Build Coastguard Worker 47*9880d681SAndroid Build Coastguard WorkerRegister stackification uses the EXPR_STACK physical register to impose 48*9880d681SAndroid Build Coastguard Workerordering dependencies on instructions with stack operands. This is pessimistic; 49*9880d681SAndroid Build Coastguard Workerwe should consider alternate ways to model stack dependencies. 50*9880d681SAndroid Build Coastguard Worker 51*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 52*9880d681SAndroid Build Coastguard Worker 53*9880d681SAndroid Build Coastguard WorkerLots of things could be done in WebAssemblyTargetTransformInfo.cpp. Similarly, 54*9880d681SAndroid Build Coastguard Workerthere are numerous optimization-related hooks that can be overridden in 55*9880d681SAndroid Build Coastguard WorkerWebAssemblyTargetLowering. 56*9880d681SAndroid Build Coastguard Worker 57*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 58*9880d681SAndroid Build Coastguard Worker 59*9880d681SAndroid Build Coastguard WorkerInstead of the OptimizeReturned pass, which should consider preserving the 60*9880d681SAndroid Build Coastguard Worker"returned" attribute through to MachineInstrs and extending the StoreResults 61*9880d681SAndroid Build Coastguard Workerpass to do this optimization on calls too. That would also let the 62*9880d681SAndroid Build Coastguard WorkerWebAssemblyPeephole pass clean up dead defs for such calls, as it does for 63*9880d681SAndroid Build Coastguard Workerstores. 64*9880d681SAndroid Build Coastguard Worker 65*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 66*9880d681SAndroid Build Coastguard Worker 67*9880d681SAndroid Build Coastguard WorkerConsider implementing optimizeSelect, optimizeCompareInstr, optimizeCondBranch, 68*9880d681SAndroid Build Coastguard WorkeroptimizeLoadInstr, and/or getMachineCombinerPatterns. 69*9880d681SAndroid Build Coastguard Worker 70*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 71*9880d681SAndroid Build Coastguard Worker 72*9880d681SAndroid Build Coastguard WorkerFind a clean way to fix the problem which leads to the Shrink Wrapping pass 73*9880d681SAndroid Build Coastguard Workerbeing run after the WebAssembly PEI pass. 74*9880d681SAndroid Build Coastguard Worker 75*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 76*9880d681SAndroid Build Coastguard Worker 77*9880d681SAndroid Build Coastguard WorkerWhen setting multiple local variables to the same constant, we currently get 78*9880d681SAndroid Build Coastguard Workercode like this: 79*9880d681SAndroid Build Coastguard Worker 80*9880d681SAndroid Build Coastguard Worker i32.const $4=, 0 81*9880d681SAndroid Build Coastguard Worker i32.const $3=, 0 82*9880d681SAndroid Build Coastguard Worker 83*9880d681SAndroid Build Coastguard WorkerIt could be done with a smaller encoding like this: 84*9880d681SAndroid Build Coastguard Worker 85*9880d681SAndroid Build Coastguard Worker i32.const $push5=, 0 86*9880d681SAndroid Build Coastguard Worker tee_local $push6=, $4=, $pop5 87*9880d681SAndroid Build Coastguard Worker copy_local $3=, $pop6 88*9880d681SAndroid Build Coastguard Worker 89*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 90*9880d681SAndroid Build Coastguard Worker 91*9880d681SAndroid Build Coastguard WorkerWebAssembly registers are implicitly initialized to zero. Explicit zeroing is 92*9880d681SAndroid Build Coastguard Workertherefore often redundant and could be optimized away. 93*9880d681SAndroid Build Coastguard Worker 94*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 95*9880d681SAndroid Build Coastguard Worker 96*9880d681SAndroid Build Coastguard WorkerSmall indices may use smaller encodings than large indices. 97*9880d681SAndroid Build Coastguard WorkerWebAssemblyRegColoring and/or WebAssemblyRegRenumbering should sort registers 98*9880d681SAndroid Build Coastguard Workeraccording to their usage frequency to maximize the usage of smaller encodings. 99*9880d681SAndroid Build Coastguard Worker 100*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 101*9880d681SAndroid Build Coastguard Worker 102*9880d681SAndroid Build Coastguard WorkerWhen the last statement in a function body computes the return value, it can 103*9880d681SAndroid Build Coastguard Workerjust let that value be the exit value of the outermost block, rather than 104*9880d681SAndroid Build Coastguard Workerneeding an explicit return operation. 105*9880d681SAndroid Build Coastguard Worker 106*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 107*9880d681SAndroid Build Coastguard Worker 108*9880d681SAndroid Build Coastguard WorkerMany cases of irreducible control flow could be transformed more optimally 109*9880d681SAndroid Build Coastguard Workerthan via the transform in WebAssemblyFixIrreducibleControlFlow.cpp. 110*9880d681SAndroid Build Coastguard Worker 111*9880d681SAndroid Build Coastguard WorkerIt may also be worthwhile to do transforms before register coloring, 112*9880d681SAndroid Build Coastguard Workerparticularly when duplicating code, to allow register coloring to be aware of 113*9880d681SAndroid Build Coastguard Workerthe duplication. 114*9880d681SAndroid Build Coastguard Worker 115*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 116*9880d681SAndroid Build Coastguard Worker 117*9880d681SAndroid Build Coastguard WorkerWebAssemblyRegStackify could use AliasAnalysis to reorder loads and stores more 118*9880d681SAndroid Build Coastguard Workeraggressively. 119*9880d681SAndroid Build Coastguard Worker 120*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 121*9880d681SAndroid Build Coastguard Worker 122*9880d681SAndroid Build Coastguard WorkerWebAssemblyRegStackify is currently a greedy algorithm. This means that, for 123*9880d681SAndroid Build Coastguard Workerexample, a binary operator will stackify with its user before its operands. 124*9880d681SAndroid Build Coastguard WorkerHowever, if moving the binary operator to its user moves it to a place where 125*9880d681SAndroid Build Coastguard Workerits operands can't be moved to, it would be better to leave it in place, or 126*9880d681SAndroid Build Coastguard Workerperhaps move it up, so that it can stackify its operands. A binary operator 127*9880d681SAndroid Build Coastguard Workerhas two operands and one result, so in such cases there could be a net win by 128*9880d681SAndroid Build Coastguard Workerprefering the operands. 129*9880d681SAndroid Build Coastguard Worker 130*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 131*9880d681SAndroid Build Coastguard Worker 132*9880d681SAndroid Build Coastguard WorkerInstruction ordering has a significant influence on register stackification and 133*9880d681SAndroid Build Coastguard Workercoloring. Consider experimenting with the MachineScheduler (enable via 134*9880d681SAndroid Build Coastguard WorkerenableMachineScheduler) and determine if it can be configured to schedule 135*9880d681SAndroid Build Coastguard Workerinstructions advantageously for this purpose. 136*9880d681SAndroid Build Coastguard Worker 137*9880d681SAndroid Build Coastguard Worker//===---------------------------------------------------------------------===// 138