416b21c18d
Use a better algorithm for resolving interferences in virtual registers. This improves code quality by generating much fewer copies on some complicated functions. After the initial union-find phase, the check_vreg() function uses a Budimlic forest to check for interference between the values in the virtual registers, as before. All the interference-free vregs are done. Others are passed to synthesize_vreg() which dissolves the vreg and then attempts to rebuild one or more vregs from the contained values. The pairwise interference checks use *virtual copies* to make sure that any future conflicts can be resolved by inserting a copy instruction. This technique was not present in the old coalescer which caused some correctness issues. This coalescing algorithm makes much better code, and it is generally a bit slower than before. Some of the slowdown is made up by the following passes being faster because they have to process less code. Example 1, the Python interpreter which contains a very large function with a lot of variables. Before: 15.664 0.011 Register allocation 1.535 1.535 RA liveness analysis 2.872 1.911 RA coalescing CSSA 4.436 4.436 RA spilling 2.610 2.598 RA reloading 4.200 4.199 RA coloring After: 9.795 0.013 Register allocation 1.372 1.372 RA liveness analysis 6.231 6.227 RA coalescing CSSA 0.712 0.712 RA spilling 0.598 0.598 RA reloading 0.869 0.869 RA coloring Coalescing is more than twice as slow, but because of the vastly better code quality, overall register allocation time is improved by 37%. Example 2, the clang compiler. Before: 57.148 0.035 Register allocation 9.630 9.630 RA liveness analysis 7.210 7.169 RA coalescing CSSA 9.972 9.972 RA spilling 11.602 11.572 RA reloading 18.698 18.672 RA coloring After: 64.792 0.042 Register allocation 8.630 8.630 RA liveness analysis 22.937 22.928 RA coalescing CSSA 8.684 8.684 RA spilling 9.559 9.551 RA reloading 14.939 14.936 RA coloring Here coalescing is 3x slower, but overall regalloc time only regresses by 13%. Most examples are less extreme than these two. They just get better code at about the same compile time.
=======================
Cretonne Code Generator
=======================
Cretonne is a low-level retargetable code generator. It translates a
target-independent intermediate language into executable machine code.
*This is a work in progress that is not yet functional.*
.. image:: https://readthedocs.org/projects/cretonne/badge/?version=latest
:target: https://cretonne.readthedocs.io/en/latest/?badge=latest
:alt: Documentation Status
.. image:: https://travis-ci.org/stoklund/cretonne.svg?branch=master
:target: https://travis-ci.org/stoklund/cretonne
:alt: Build Status
Cretonne is designed to be a code generator for WebAssembly with these design
goals:
Portable semantics
As far as possible, Cretonne's input language has well-defined semantics
that are the same on all target architectures. The semantics are usually
the same as WebAssembly's.
Fast sandbox verification
Cretonne's input language has a safe subset for sandboxed code. No advanced
analysis is required to verify memory safety as long as only the safe
subset is used. The safe subset is expressive enough to implement
WebAssembly.
Scalable performance
Cretonne can be configured to generate code as quickly as possible, or it
can generate very good code at the cost of slower compile times.
Predictable performance
When optimizing, Cretonne focuses on adapting the target-independent IL to
the quirks of the target architecture. There are no advanced optimizations
that sometimes work, sometimes fail.
For more information, see
`the documentation <https://cretonne.readthedocs.io/en/latest/?badge=latest>`_.
Building Cretonne
-----------------
Cretonne is using the Cargo package manager format. First, ensure you have
installed a current stable rust (stable, beta, and nightly should all work, but
only stable and beta are tested consistently). Then, change the working
directory to your clone of cretonne and run::
cargo build
This will create a *target/debug* directory where you can find the generated
binary.
To build the optimized binary for release::
cargo build --release
You can then run tests with::
./test-all.sh
You may need to install the *wat2wasm* tool from the `wabt
<https://github.com/WebAssembly/wabt>`_ project in order to run all of the
WebAssembly tests. Tests requiring wat2wasm are ignored if the tool is not
installed.
Building the documentation
--------------------------
To build the Cretonne documentation, you need the `Sphinx documentation
generator <http://www.sphinx-doc.org/>`_::
$ pip install sphinx sphinx-autobuild sphinx_rtd_theme
$ cd cretonne/docs
$ make html
$ open _build/html/index.html
We don't support Sphinx versions before 1.4 since the format of index tuples
has changed.