xref: /aosp_15_r20/external/llvm/lib/Target/WebAssembly/README.txt (revision 9880d6810fe72a1726cb53787c6711e909410d58)
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