Home | History | Annotate | only in /external/swiftshader/third_party/llvm-7.0/llvm/lib/Target/WebAssembly
Up to higher level directory
NameDateSize
AsmParser/22-Oct-2020
CMakeLists.txt22-Oct-20202.1K
Disassembler/22-Oct-2020
InstPrinter/22-Oct-2020
known_gcc_test_failures.txt22-Oct-20202K
LLVMBuild.txt22-Oct-20201.1K
MCTargetDesc/22-Oct-2020
README.txt22-Oct-20208.3K
TargetInfo/22-Oct-2020
WebAssembly.h22-Oct-20203.5K
WebAssembly.td22-Oct-20203.6K
WebAssemblyAddMissingPrototypes.cpp22-Oct-20204.8K
WebAssemblyArgumentMove.cpp22-Oct-20203.3K
WebAssemblyAsmPrinter.cpp22-Oct-202010.6K
WebAssemblyAsmPrinter.h22-Oct-20202.7K
WebAssemblyCallIndirectFixup.cpp22-Oct-20204.8K
WebAssemblyCFGSort.cpp22-Oct-202010.2K
WebAssemblyCFGStackify.cpp22-Oct-202014.7K
WebAssemblyExceptionInfo.cpp22-Oct-20206.3K
WebAssemblyExceptionInfo.h22-Oct-20206.2K
WebAssemblyExplicitLocals.cpp22-Oct-202014.3K
WebAssemblyFastISel.cpp22-Oct-202040K
WebAssemblyFixFunctionBitcasts.cpp22-Oct-20208.1K
WebAssemblyFixIrreducibleControlFlow.cpp22-Oct-202010.6K
WebAssemblyFrameLowering.cpp22-Oct-20209.5K
WebAssemblyFrameLowering.h22-Oct-20202.1K
WebAssemblyInstrAtomics.td22-Oct-202033.3K
WebAssemblyInstrCall.td22-Oct-20208.1K
WebAssemblyInstrControl.td22-Oct-20207.8K
WebAssemblyInstrConv.td22-Oct-202012.7K
WebAssemblyInstrExceptRef.td22-Oct-20201.3K
WebAssemblyInstrFloat.td22-Oct-20204.4K
WebAssemblyInstrFormats.td22-Oct-20208.4K
WebAssemblyInstrInfo.cpp22-Oct-20206.8K
WebAssemblyInstrInfo.h22-Oct-20202.3K
WebAssemblyInstrInfo.td22-Oct-202012.1K
WebAssemblyInstrInteger.td22-Oct-20204.3K
WebAssemblyInstrMemory.td22-Oct-202023.1K
WebAssemblyInstrSIMD.td22-Oct-2020663
WebAssemblyISD.def22-Oct-2020786
WebAssemblyISelDAGToDAG.cpp22-Oct-20203.6K
WebAssemblyISelLowering.cpp22-Oct-202035.8K
WebAssemblyISelLowering.h22-Oct-20204.4K
WebAssemblyLateEHPrepare.cpp22-Oct-202014K
WebAssemblyLowerBrUnless.cpp22-Oct-20205.5K
WebAssemblyLowerEmscriptenEHSjLj.cpp22-Oct-202044.7K
WebAssemblyLowerGlobalDtors.cpp22-Oct-20207K
WebAssemblyMachineFunctionInfo.cpp22-Oct-20202.2K
WebAssemblyMachineFunctionInfo.h22-Oct-20204.3K
WebAssemblyMCInstLower.cpp22-Oct-20208.5K
WebAssemblyMCInstLower.h22-Oct-20201.5K
WebAssemblyOptimizeLiveIntervals.cpp22-Oct-20203.9K
WebAssemblyOptimizeReturned.cpp22-Oct-20202.4K
WebAssemblyPeephole.cpp22-Oct-20207.5K
WebAssemblyPrepareForLiveIntervals.cpp22-Oct-20204.3K
WebAssemblyRegColoring.cpp22-Oct-20206.3K
WebAssemblyRegisterInfo.cpp22-Oct-20205.7K
WebAssemblyRegisterInfo.h22-Oct-20201.7K
WebAssemblyRegisterInfo.td22-Oct-20202.8K
WebAssemblyRegNumbering.cpp22-Oct-20203.8K
WebAssemblyRegStackify.cpp22-Oct-202033.7K
WebAssemblyReplacePhysRegs.cpp22-Oct-20203.5K
WebAssemblyRuntimeLibcallSignatures.cpp22-Oct-202031.7K
WebAssemblyRuntimeLibcallSignatures.h22-Oct-20201.3K
WebAssemblySelectionDAGInfo.cpp22-Oct-2020674
WebAssemblySelectionDAGInfo.h22-Oct-2020882
WebAssemblySetP2AlignOperands.cpp22-Oct-20206.6K
WebAssemblyStoreResults.cpp22-Oct-20207.1K
WebAssemblySubtarget.cpp22-Oct-20202K
WebAssemblySubtarget.h22-Oct-20203.1K
WebAssemblyTargetMachine.cpp22-Oct-202013K
WebAssemblyTargetMachine.h22-Oct-20201.7K
WebAssemblyTargetObjectFile.cpp22-Oct-2020858
WebAssemblyTargetObjectFile.h22-Oct-2020931
WebAssemblyTargetTransformInfo.cpp22-Oct-20202.7K
WebAssemblyTargetTransformInfo.h22-Oct-20202.4K
WebAssemblyUtilities.cpp22-Oct-20206.6K
WebAssemblyUtilities.h22-Oct-20202.4K

README.txt

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