OLD | NEW |
1 Subzero - Fast code generator for PNaCl bitcode | 1 Subzero - Fast code generator for PNaCl bitcode |
2 =============================================== | 2 =============================================== |
3 | 3 |
4 Building | 4 Building |
5 -------- | 5 -------- |
6 | 6 |
7 You must have LLVM trunk source code available and built. See | 7 Subzero is set up to be built within the Native Client tree. Follow the |
8 http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary for | 8 `Developing PNaCl |
9 guidance. | 9 <https://sites.google.com/a/chromium.org/dev/nativeclient/pnacl/developing-pnacl
>`_ |
| 10 instructions, in particular the section on building PNaCl sources. This will |
| 11 prepare the necessary external headers and libraries that Subzero needs. |
| 12 Checking out the Native Client project also gets the pre-built clang and LLVM |
| 13 tools in ``native_client/../third_party/llvm-build/Release+Asserts/bin`` which |
| 14 are used for building Subzero. |
10 | 15 |
11 Set variables ``LLVM_SRC_PATH`` and ``LLVM_BIN_PATH`` to point to the | 16 The Subzero source is in ``native_client/toolchain_build/src/subzero``. From |
12 appropriate directories in the LLVM source and build directories. These can be | 17 within that directory, ``git checkout master && git pull`` to get the latest |
13 set as environment variables, or you can modify the top-level Makefile. | 18 version of Subzero source code. |
14 | 19 |
15 Run ``make`` at the top level to build the main target ``llvm2ice``. | 20 The Makefile is designed to be used as part of the higher level LLVM build |
| 21 system. To build manually, use the ``Makefile.standalone``. There are several |
| 22 build configurations from the command line:: |
| 23 |
| 24 make -f Makefile.standalone |
| 25 make -f Makefile.standalone DEBUG=1 |
| 26 make -f Makefile.standalone NOASSERT=1 |
| 27 make -f Makefile.standalone DEBUG=1 NOASSERT=1 |
| 28 make -f Makefile.standalone MINIMAL=1 |
| 29 |
| 30 ``DEBUG=1`` builds without optimizations and is good when running the translator |
| 31 inside a debugger. ``NOASSERT=1`` disables assertions and is the preferred |
| 32 configuration for performance testing the translator. ``MINIMAL=1`` attempts to |
| 33 minimize the size of the translator by compiling out everything unnecessary. |
| 34 |
| 35 The result of the ``make`` command is the target ``llvm2ice`` in the current |
| 36 directory. |
16 | 37 |
17 ``llvm2ice`` | 38 ``llvm2ice`` |
18 ------------ | 39 ------------ |
19 | 40 |
20 The ``llvm2ice`` program uses the LLVM infrastructure to parse an LLVM bitcode | 41 The ``llvm2ice`` program parses a pexe or an LLVM bitcode file and translates it |
21 file and translate it into ICE. It then invokes ICE's translate method to lower | 42 into ICE (Subzero's intermediate representation). It then invokes the ICE |
22 it to target-specific machine code, dumping the IR at various stages of the | 43 translate method to lower it to target-specific machine code, optionally dumping |
23 translation. | 44 the intermediate representation at various stages of the translation. |
24 | 45 |
25 The program can be run as follows:: | 46 The program can be run as follows:: |
26 | 47 |
27 ../llvm2ice ./ir_samples/<file>.ll | 48 ../llvm2ice ./path/to/<file>.pexe |
28 ../llvm2ice ./tests_lit/llvm2ice_tests/<file>.ll | 49 ../llvm2ice ./tests_lit/llvm2ice_tests/<file>.ll |
29 | 50 |
30 At this time, ``llvm2ice`` accepts a few arguments: | 51 At this time, ``llvm2ice`` accepts a number of arguments, including the |
| 52 following: |
31 | 53 |
32 ``-help`` -- Show available arguments and possible values. | 54 ``-help`` -- Show available arguments and possible values. (Note: this |
| 55 unfortunately also pulls in some LLVM-specific options that are reported but |
| 56 that Subzero doesn't use.) |
33 | 57 |
34 ``-notranslate`` -- Suppress the ICE translation phase, which is useful if | 58 ``-notranslate`` -- Suppress the ICE translation phase, which is useful if |
35 ICE is missing some support. | 59 ICE is missing some support. |
36 | 60 |
37 ``-target=<TARGET>`` -- Set the target architecture. The default is x8632. | 61 ``-target=<TARGET>`` -- Set the target architecture. The default is x8632. |
38 Future targets include x8664, arm32, and arm64. | 62 Future targets include x8664, arm32, and arm64. |
39 | 63 |
| 64 ``-integrated-as=0|1`` -- Disable/enable the integrated assembler. |
| 65 |
40 ``-O<LEVEL>`` -- Set the optimization level. Valid levels are ``2``, ``1``, | 66 ``-O<LEVEL>`` -- Set the optimization level. Valid levels are ``2``, ``1``, |
41 ``0``, ``-1``, and ``m1``. Levels ``-1`` and ``m1`` are synonyms, and | 67 ``0``, ``-1``, and ``m1``. Levels ``-1`` and ``m1`` are synonyms, and |
42 represent the minimum optimization and worst code quality, but fastest code | 68 represent the minimum optimization and worst code quality, but fastest code |
43 generation. | 69 generation. |
44 | 70 |
45 ``-verbose=<list>`` -- Set verbosity flags. This argument allows a | 71 ``-verbose=<list>`` -- Set verbosity flags. This argument allows a |
46 comma-separated list of values. The default is ``none``, and the value | 72 comma-separated list of values. The default is ``none``, and the value |
47 ``inst,pred`` will roughly match the .ll bitcode file. Of particular use | 73 ``inst,pred`` will roughly match the .ll bitcode file. Of particular use |
48 are ``all`` and ``none``. | 74 are ``all`` and ``none``. |
49 | 75 |
50 ``-o <FILE>`` -- Set the assembly output file name. Default is stdout. | 76 ``-o <FILE>`` -- Set the assembly output file name. Default is stdout. |
51 | 77 |
52 ``-log <FILE>`` -- Set the file name for diagnostic output (whose level is | 78 ``-log <FILE>`` -- Set the file name for diagnostic output (whose level is |
53 controlled by ``-verbose``). Default is stdout. | 79 controlled by ``-verbose``). Default is stdout. |
54 | 80 |
55 See ir_samples/README.rst for more details. | 81 ``-timing`` -- Dump some pass timing information after translating the input |
| 82 file. |
56 | 83 |
57 Running the test suite | 84 Running the test suite |
58 ---------------------- | 85 ---------------------- |
59 | 86 |
60 Subzero uses the LLVM ``lit`` testing tool for its test suite, which lives in | 87 Subzero uses the LLVM ``lit`` testing tool for part of its test suite, which |
61 ``tests_lit``. To execute the test suite, first build Subzero, and then run:: | 88 lives in ``tests_lit``. To execute the test suite, first build Subzero, and then |
| 89 run:: |
62 | 90 |
63 python <path_to_lit.py> -sv tests_lit | 91 make -f Makefile.standalone check-lit |
64 | 92 |
65 ``path_to_lit`` is the direct path to the lit script in the LLVM source | 93 There is also a suite of cross tests in the ``crosstest`` directory. A cross |
66 (``$LLVM_SRC_PATH/utils/lit/lit.py``). | 94 test takes a test bitcode file implementing some unit tests, and translates it |
| 95 twice, once with Subzero and once with LLVM's known-good ``llc`` translator. |
| 96 The Subzero-translated symbols are specially mangled to avoid multiple |
| 97 definition errors from the linker. Both translated versions are linked together |
| 98 with a driver program that calls each version of each unit test with a variety |
| 99 of interesting inputs and compares the results for equality. The cross tests |
| 100 are currently invoked by running the ``runtests.sh`` script. |
67 | 101 |
68 The above ``lit`` execution also needs the LLVM binary path in the | 102 A convenient way to run both the lit tests and the cross tests is:: |
69 ``LLVM_BIN_PATH`` env var. | |
70 | 103 |
71 Assuming the LLVM paths are set up, ``make check`` is a convenient way to run | 104 make -f Makefile.standalone check |
72 the test suite. | |
73 | 105 |
74 Assembling ``llvm2ice`` output | 106 Assembling ``llvm2ice`` output |
75 ------------------------------ | 107 ------------------------------ |
76 | 108 |
77 Currently ``llvm2ice`` produces textual assembly code in a structure suitable | 109 Currently ``llvm2ice`` produces textual assembly code in a structure suitable |
78 for input to ``llvm-mc`` and currently using "intel" assembly syntax. The first | 110 for input to ``llvm-mc``. An object file can be produced using the command:: |
79 line of output is a convenient comment indicating how to pipe the output to | 111 |
80 ``llvm-mc`` to produce object code. | 112 llvm-mc -arch=x86 -filetype=obj -o=MyObj.o |
| 113 |
| 114 In the future, the integrated assembler will directly produce ELF object files. |
| 115 |
| 116 Building a translated binary |
| 117 ---------------------------- |
| 118 |
| 119 There is a helper script, ``pydir/szbuild.py``, that translates a finalized pexe |
| 120 into a fully linked executable. Run it with ``-help`` for extensive |
| 121 documentation. |
| 122 |
| 123 By default, ``szbuild.py`` builds an executable using only Subzero translation, |
| 124 but it can also be used to produce hybrid Subzero/``llc`` binaries (``llc`` is |
| 125 the name of the LLVM translator) for bisection-based debugging. In bisection |
| 126 debugging mode, the pexe is translated using both Subzero and ``llc``, and the |
| 127 resulting object files are combined into a single executable using symbol |
| 128 weakening and other linker tricks to control which Subzero symbols and which |
| 129 ``llc`` symbols take precedence. This is controlled by the ``-include`` and |
| 130 ``-exclude`` arguments. These can be used to rapidly find a single function |
| 131 that Subzero translates incorrectly leading to incorrect output. |
| 132 |
| 133 There is another helper script, ``pydir/szbuild_spec2k.py``, that runs |
| 134 ``szbuild.py`` on one or more components of the Spec2K suite. This assumes that |
| 135 Spec2K is set up in the usual place in the Native Client tree, and the finalized |
| 136 pexe files have been built. (Note: for working with Spec2K and other pexes, |
| 137 it's helpful to finalize the pexe using ``--no-strip-syms``, to preserve the |
| 138 original function and global variable names.) |
| 139 |
| 140 Status |
| 141 ------ |
| 142 |
| 143 Subzero currently translates only for the x86-32 architecture. Native Client |
| 144 sandboxing is not yet implemented. Two optimization levels, ``-Om1`` and |
| 145 ``-O2``, are implemented. |
| 146 |
| 147 The ``-Om1`` configuration is designed to be the simplest and fastest possible, |
| 148 with a minimal set of passes and transformations. |
| 149 |
| 150 * Simple Phi lowering before target lowering, by generating temporaries and |
| 151 adding assignments to the end of predecessor blocks. |
| 152 |
| 153 * Simple register allocation limited to pre-colored and infinite-weight |
| 154 Variables. |
| 155 |
| 156 The ``-O2`` configuration is designed to use all optimizations available and |
| 157 produce the best code. |
| 158 |
| 159 * Address mode inference to leverage the complex x86 addressing modes. |
| 160 |
| 161 * Compare/branch fusing based on liveness/last-use analysis. |
| 162 |
| 163 * Global, linear-scan register allocation. |
| 164 |
| 165 * Advanced phi lowering after target lowering and global register allocation, |
| 166 via edge splitting, topological sorting of the parallel moves, and final local |
| 167 register allocation. |
| 168 |
| 169 * Stack slot coalescing to reduce frame size. |
| 170 |
| 171 * Branch optimization to reduce the number of branches to the following block. |
OLD | NEW |