1bbc529ef980c722aaaa65393c19245b7c7aa729
The fuzzer bugs #219 and #227 are both cases where the register allocator coloring pass "runs out of registers". What's really happening is that the constraint solver failed to find a solution, even when one existed. Suppose we have three solver variables: v0(GPR, out, global) v1(GPR, in) v2(GPR, in, out) And suppose registers %r0 and %r1 are available on both input and output sides of the instruction, but only %r1 is available for global outputs. A valid solution would be: v0 -> %r1 v1 -> %r1 v2 -> %r0 However, the solver would pick registers for the three values in numerical order because v1 and v2 have the same domain size (=2). This would assign v1 -> %r0 and then fail to find a free register for v2. Fix this by prioritizing in+out variables over single-sided variables even when their domains are equal. This means the v2 gets assigned a register before v1, and it gets a chance to pick a register that is still available on both in and out sides. Also try to avoid depending on value numbers in the solver. These bugs were hard to reproduce because a test case invariably would have different value numbers, causing the solver to order its variables differently and succeed. Throw in the previous solution and original register assignments as tie breakers which are stable and not dependent on value numbers. This is still not a substitute for a proper solver search algorithm that we will probably have to write eventually. Fixes #219 Fixes #227
=======================
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.
Description
Languages
Rust
77.8%
WebAssembly
20.6%
C
1.3%