Rename Cretonne to Cranelift!

README.rst

@@ -1,61 +1,61 @@
-=======================
+========================
-Cretonne Code Generator
+Cranelift Code Generator
-=======================
+========================
 
-Cretonne is a low-level retargetable code generator. It translates a `target-independent
+Cranelift is a low-level retargetable code generator. It translates a `target-independent
-intermediate representation <https://cretonne.readthedocs.io/en/latest/langref.html>`_ into executable
+intermediate representation <https://cranelift.readthedocs.io/en/latest/langref.html>`_ into executable
 machine code.
 
-.. image:: https://readthedocs.org/projects/cretonne/badge/?version=latest
+.. image:: https://readthedocs.org/projects/cranelift/badge/?version=latest
-    :target: https://cretonne.readthedocs.io/en/latest/?badge=latest
+    :target: https://cranelift.readthedocs.io/en/latest/?badge=latest
     :alt: Documentation Status
 
-.. image:: https://travis-ci.org/cretonne/cretonne.svg?branch=master
+.. image:: https://travis-ci.org/CraneStation/cranelift.svg?branch=master
-    :target: https://travis-ci.org/cretonne/cretonne
+    :target: https://travis-ci.org/CraneStation/cranelift
     :alt: Build Status
 
-.. image:: https://badges.gitter.im/cretonne/cretonne.svg
+.. image:: https://badges.gitter.im/CraneStation/CraneStation.svg
-    :target: https://gitter.im/cretonne/Lobby/~chat
+    :target: https://gitter.im/CraneStation/Lobby/~chat
     :alt: Gitter chat
 
 For more information, see `the documentation
-<https://cretonne.readthedocs.io/en/latest/?badge=latest>`_.
+<https://cranelift.readthedocs.io/en/latest/?badge=latest>`_.
 
 Status
 ------
 
-Cretonne currently supports enough functionality to run a wide variety of
+Cranelift currently supports enough functionality to run a wide variety of
 programs, including all the functionality needed to execute WebAssembly MVP
 functions, although it needs to be used within an external WebAssembly
 embedding to be part of a complete WebAssembly implementation.
 
 The x86-64 backend is currently the most complete and stable; other
-architectures are in various stages of development. Cretonne currently supports
+architectures are in various stages of development. Cranelift currently supports
 the System V AMD64 ABI calling convention used on many platforms, but does not
 yet support the Windows x64 calling convention. The performance of code
-produced by Cretonne is not yet impressive, though we have plans to fix that.
+produced by Cranelift is not yet impressive, though we have plans to fix that.
 
 The core codegen crates have minimal dependencies, support
 `no_std <#building-with-no-std>`_ mode, and do not require any host
 floating-point support.
 
-Cretonne does not yet perform mitigations for Spectre or related security
+Cranelift does not yet perform mitigations for Spectre or related security
 issues, though it may do so in the future. It does not currently make any
 security-relevant instruction timing guarantees. It has seen a fair amount
 of testing and fuzzing, although more work is needed before it would be
 ready for a production use case.
 
-Cretonne's APIs are not yet stable.
+Cranelift's APIs are not yet stable.
 
-Cretonne currently supports Rust 1.22.1 and later. We intend to always support
+Cranelift currently supports Rust 1.22.1 and later. We intend to always support
 the latest *stable* Rust. And, we currently support the version of Rust in the
 latest Ubuntu LTS, although whether we will always do so is not yet determined.
-Cretonne requires Python 2.7 or Python 3 to build.
+Cranelift requires Python 2.7 or Python 3 to build.
 
 Planned uses
 ------------
 
-Cretonne is designed to be a code generator for WebAssembly, but it is general enough to be useful
+Cranelift is designed to be a code generator for WebAssembly, but it is general enough to be useful
 elsewhere too. The initial planned uses that affected its design are:
 
 1. `WebAssembly compiler for the SpiderMonkey engine in Firefox
@@ -64,13 +64,13 @@ elsewhere too. The initial planned uses that affected its design are:
    <spidermonkey.rst#phase-2-ionmonkey>`_.
 3. `Debug build backend for the Rust compiler <rustc.rst>`_.
 
-Building Cretonne
+Building Cranelift
------------------
+------------------
 
-Cretonne is using the Cargo package manager format. First, ensure you have
+Cranelift 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::
+directory to your clone of cranelift and run::
 
     cargo build
 
@@ -89,30 +89,30 @@ Building with `no_std`
 ----------------------
 
 The following crates support `no_std`:
- - `cretonne-entity`
+ - `cranelift-entity`
- - `cretonne-codegen`
+ - `cranelift-codegen`
- - `cretonne-frontend`
+ - `cranelift-frontend`
- - `cretonne-native`
+ - `cranelift-native`
- - `cretonne-wasm`
+ - `cranelift-wasm`
- - `cretonne-module`
+ - `cranelift-module`
- - `cretonne-simplejit`
+ - `cranelift-simplejit`
- - `cretonne`
+ - `cranelift`
 
 To use `no_std` mode, disable the `std` feature and enable the `core` feature.
 This currently requires nightly rust.
 
-For example, to build `cretonne-codegen`:
+For example, to build `cranelift-codegen`:
 
 .. code-block:: sh
 
     cd lib/codegen
     cargo build --no-default-features --features core
 
-Or, when using `cretonne-codegen` as a dependency (in Cargo.toml):
+Or, when using `cranelift-codegen` as a dependency (in Cargo.toml):
 
 .. code-block::
 
-    [dependency.cretonne-codegen]
+    [dependency.cranelift-codegen]
     ...
     default-features = false
     features = ["core"]
@@ -125,7 +125,7 @@ build and test `no_std` when submitting patches. Accordingly, the
 There is a separate `./test-no_std.sh` script that tests the `no_std`
 support in packages which support it.
 
-It's important to note that cretonne still needs liballoc to compile.
+It's important to note that cranelift still needs liballoc to compile.
 Thus, whatever environment is used must implement an allocator.
 
 Also, to allow the use of HashMaps with `no_std`, an external crate called
@@ -136,11 +136,11 @@ Just something to think about.
 Building the documentation
 --------------------------
 
-To build the Cretonne documentation, you need the `Sphinx documentation
+To build the Cranelift documentation, you need the `Sphinx documentation
 generator <https://www.sphinx-doc.org/>`_::
 
     $ pip install sphinx sphinx-autobuild sphinx_rtd_theme
-    $ cd cretonne/docs
+    $ cd cranelift/docs
     $ make html
     $ open _build/html/index.html
 

clippy-all.sh

@@ -2,6 +2,6 @@
 set -euo pipefail
 
 # Check all sources with clippy.
-# In the cton-util crate (root dir) clippy will only work with nightly cargo -
+# In the clif-util crate (root dir) clippy will only work with nightly cargo -
 # there is a bug where it will reject the commands passed to it by cargo 0.25.0
 exec cargo +nightly clippy --all

cranelift/.gitignore

@@ -7,7 +7,7 @@ tags
 target
 Cargo.lock
 .*.rustfmt
-cretonne.dbg*
+cranelift.dbg*
 .mypy_cache
 rusty-tags.*
 docs/_build

cranelift/Cargo.toml

@@ -1,29 +1,29 @@
 [package]
-name = "cretonne-tools"
+name = "cranelift-tools"
-authors = ["The Cretonne Project Developers"]
+authors = ["The Cranelift Project Developers"]
 version = "0.13.0"
-description = "Binaries for testing the Cretonne libraries"
+description = "Binaries for testing the Cranelift libraries"
 license = "Apache-2.0 WITH LLVM-exception"
-documentation = "https://cretonne.readthedocs.io/"
+documentation = "https://cranelift.readthedocs.io/"
-repository = "https://github.com/cretonne/cretonne"
+repository = "https://github.com/cranelift/cranelift"
 publish = false
 
 [[bin]]
-name = "cton-util"
+name = "clif-util"
-path = "src/cton-util.rs"
+path = "src/clif-util.rs"
 
 [dependencies]
 cfg-if = "0.1"
-cretonne-codegen = { path = "lib/codegen", version = "0.13.0" }
+cranelift-codegen = { path = "lib/codegen", version = "0.13.0" }
-cretonne-reader = { path = "lib/reader", version = "0.13.0" }
+cranelift-reader = { path = "lib/reader", version = "0.13.0" }
-cretonne-frontend = { path = "lib/frontend", version = "0.13.0" }
+cranelift-frontend = { path = "lib/frontend", version = "0.13.0" }
-cretonne-wasm = { path = "lib/wasm", version = "0.13.0", optional = true }
+cranelift-wasm = { path = "lib/wasm", version = "0.13.0", optional = true }
-cretonne-native = { path = "lib/native", version = "0.13.0" }
+cranelift-native = { path = "lib/native", version = "0.13.0" }
-cretonne-filetests = { path = "lib/filetests", version = "0.13.0" }
+cranelift-filetests = { path = "lib/filetests", version = "0.13.0" }
-cretonne-module = { path = "lib/module", version = "0.13.0" }
+cranelift-module = { path = "lib/module", version = "0.13.0" }
-cretonne-faerie = { path = "lib/faerie", version = "0.13.0" }
+cranelift-faerie = { path = "lib/faerie", version = "0.13.0" }
-cretonne-simplejit = { path = "lib/simplejit", version = "0.13.0" }
+cranelift-simplejit = { path = "lib/simplejit", version = "0.13.0" }
-cretonne = { path = "lib/umbrella", version = "0.13.0" }
+cranelift = { path = "lib/umbrella", version = "0.13.0" }
 filecheck = "0.3.0"
 docopt = "1"
 serde = "1.0.8"
@@ -36,7 +36,7 @@ target-lexicon = "0.0.2"
 [features]
 default = ["disas", "wasm"]
 disas = ["capstone"]
-wasm = ["wabt", "cretonne-wasm"]
+wasm = ["wabt", "cranelift-wasm"]
 
 [workspace]
 

cranelift/FUZZING.md

@@ -1,6 +1,6 @@
 # Fuzzing
 
-This document describes how to fuzz cretonne with [`cargo-fuzz`](https://github.com/rust-fuzz/cargo-fuzz). The fuzz targets use `wasm-opt` from [`binaryen-rs`](https://github.com/pepyakin/binaryen-rs) to generate valid WebAssembly modules from the fuzzed input supplied by `cargo-fuzz` (via [libfuzzer](http://llvm.org/docs/LibFuzzer.html)). In this scheme coverage feedback from both cretonne and the `wasm-opt` input generation code is used to inform the fuzzer.
+This document describes how to fuzz cranelift with [`cargo-fuzz`](https://github.com/rust-fuzz/cargo-fuzz). The fuzz targets use `wasm-opt` from [`binaryen-rs`](https://github.com/pepyakin/binaryen-rs) to generate valid WebAssembly modules from the fuzzed input supplied by `cargo-fuzz` (via [libfuzzer](http://llvm.org/docs/LibFuzzer.html)). In this scheme coverage feedback from both cranelift and the `wasm-opt` input generation code is used to inform the fuzzer.
 
 # Usage
 

cranelift/docs/Makefile

@@ -5,7 +5,7 @@
 SPHINXOPTS    =
 SPHINXBUILD   = sphinx-build
 SPHINXABUILD  = sphinx-autobuild
-SPHINXPROJ    = cretonne
+SPHINXPROJ    = cranelift
 SOURCEDIR     = .
 BUILDDIR      = _build
 

cranelift/docs/clif_domain.py

@@ -2,11 +2,11 @@
 #
 # Sphinx domain for documenting compiler intermediate representations.
 #
-# This defines a 'cton' Sphinx domain with the following directives and roles:
+# This defines a 'clif' Sphinx domain with the following directives and roles:
 #
-# .. cton::type:: type
+# .. clif::type:: type
 #     Document an IR type.
-# .. cton:inst:: v0, v1 = inst op0, op1
+# .. clif:inst:: v0, v1 = inst op0, op1
 #     Document an IR instruction.
 #
 from __future__ import absolute_import
@@ -27,12 +27,12 @@ from sphinx.util.nodes import make_refnode
 import sphinx.ext.autodoc
 
 
-class CtonObject(ObjectDescription):
+class ClifObject(ObjectDescription):
     """
-    Any kind of Cretonne IR object.
+    Any kind of Cranelift IR object.
 
     This is a shared base class for the different kinds of indexable objects
-    in the Cretonne IR reference.
+    in the Cranelift IR reference.
     """
     option_spec = {
         'noindex': directives.flag,
@@ -54,10 +54,10 @@ class CtonObject(ObjectDescription):
             signode['ids'].append(targetname)
             signode['first'] = (not self.names)
             self.state.document.note_explicit_target(signode)
-            inv = self.env.domaindata['cton']['objects']
+            inv = self.env.domaindata['clif']['objects']
             if name in inv:
                 self.state_machine.reporter.warning(
-                    'duplicate Cretonne object description of %s, ' % name +
+                    'duplicate Cranelift object description of %s, ' % name +
                     'other instance in ' + self.env.doc2path(inv[name][0]),
                     line=self.lineno)
             inv[name] = (self.env.docname, self.objtype)
@@ -97,8 +97,8 @@ def parse_type(name, signode):
     return re_str
 
 
-class CtonType(CtonObject):
+class ClifType(ClifObject):
-    """A Cretonne IR type description."""
+    """A Cranelift IR type description."""
 
     def handle_signature(self, sig, signode):
         """
@@ -126,8 +126,8 @@ def parse_params(s, signode):
         signode += nodes.emphasis(p, p)
 
 
-class CtonInst(CtonObject):
+class ClifInst(ClifObject):
-    """A Cretonne IR instruction."""
+    """A Cranelift IR instruction."""
 
     doc_field_types = [
         TypedField('argument', label=l_('Arguments'),
@@ -175,14 +175,14 @@ class CtonInst(CtonObject):
         return name
 
 
-class CtonInstGroup(CtonObject):
+class ClifInstGroup(ClifObject):
-    """A Cretonne IR instruction group."""
+    """A Cranelift IR instruction group."""
 
 
-class CretonneDomain(Domain):
+class CraneliftDomain(Domain):
-    """Cretonne domain for IR objects."""
+    """Cranelift domain for IR objects."""
-    name = 'cton'
+    name = 'clif'
-    label = 'Cretonne'
+    label = 'Cranelift'
 
     object_types = {
         'type': ObjType(l_('type'), 'type'),
@@ -190,9 +190,9 @@ class CretonneDomain(Domain):
     }
 
     directives = {
-        'type': CtonType,
+        'type': ClifType,
-        'inst': CtonInst,
+        'inst': ClifInst,
-        'instgroup': CtonInstGroup,
+        'instgroup': ClifInstGroup,
     }
 
     roles = {
@@ -230,16 +230,16 @@ class CretonneDomain(Domain):
         if target not in objects:
             return []
         obj = objects[target]
-        return [('cton:' + self.role_for_objtype(obj[1]),
+        return [('clif:' + self.role_for_objtype(obj[1]),
                  make_refnode(builder, fromdocname, obj[0],
                               obj[1] + '-' + target, contnode, target))]
 
 
 class TypeDocumenter(sphinx.ext.autodoc.Documenter):
-    # Invoke with .. autoctontype::
+    # Invoke with .. autocliftype::
-    objtype = 'ctontype'
+    objtype = 'cliftype'
-    # Convert into cton:type directives
+    # Convert into clif:type directives
-    domain = 'cton'
+    domain = 'clif'
     directivetype = 'type'
 
     @classmethod
@@ -262,8 +262,8 @@ class TypeDocumenter(sphinx.ext.autodoc.Documenter):
 class InstDocumenter(sphinx.ext.autodoc.Documenter):
     # Invoke with .. autoinst::
     objtype = 'inst'
-    # Convert into cton:inst directives
+    # Convert into clif:inst directives
-    domain = 'cton'
+    domain = 'clif'
     directivetype = 'inst'
 
     @classmethod
@@ -297,7 +297,7 @@ class InstDocumenter(sphinx.ext.autodoc.Documenter):
 
     def add_directive_header(self, sig):
         """Add the directive header and options to the generated content."""
-        domain = getattr(self, 'domain', 'cton')
+        domain = getattr(self, 'domain', 'clif')
         directive = getattr(self, 'directivetype', self.objtype)
         sourcename = self.get_sourcename()
         self.add_line(u'.. %s:%s:: %s' % (domain, directive, sig), sourcename)
@@ -350,8 +350,8 @@ class InstDocumenter(sphinx.ext.autodoc.Documenter):
 class InstGroupDocumenter(sphinx.ext.autodoc.ModuleLevelDocumenter):
     # Invoke with .. autoinstgroup::
     objtype = 'instgroup'
-    # Convert into cton:instgroup directives
+    # Convert into clif:instgroup directives
-    domain = 'cton'
+    domain = 'clif'
     directivetype = 'instgroup'
 
     @classmethod
@@ -365,19 +365,19 @@ class InstGroupDocumenter(sphinx.ext.autodoc.ModuleLevelDocumenter):
         super(InstGroupDocumenter, self).add_content(
                 more_content, no_docstring)
         sourcename = self.get_sourcename()
-        indexed = self.env.domaindata['cton']['objects']
+        indexed = self.env.domaindata['clif']['objects']
 
         names = [inst.name for inst in self.object.instructions]
         names.sort()
         for name in names:
             if name in indexed:
-                self.add_line(u':cton:inst:`{}`'.format(name), sourcename)
+                self.add_line(u':clif:inst:`{}`'.format(name), sourcename)
             else:
                 self.add_line(u'``{}``'.format(name), sourcename)
 
 
 def setup(app):
-    app.add_domain(CretonneDomain)
+    app.add_domain(CraneliftDomain)
     app.add_autodocumenter(TypeDocumenter)
     app.add_autodocumenter(InstDocumenter)
     app.add_autodocumenter(InstGroupDocumenter)

cranelift/docs/clif_lexer.py

@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-
 #
-# Pygments lexer for Cretonne.
+# Pygments lexer for Cranelift.
 from __future__ import absolute_import
 
 from pygments.lexer import RegexLexer, bygroups, words
@@ -12,10 +12,10 @@ def keywords(*args):
     return words(args, prefix=r'\b', suffix=r'\b')
 
 
-class CretonneLexer(RegexLexer):
+class CraneliftLexer(RegexLexer):
-    name = 'Cretonne'
+    name = 'Cranelift'
-    aliases = ['cton']
+    aliases = ['clif']
-    filenames = ['*.cton']
+    filenames = ['*.clif']
 
     tokens = {
         'root': [
@@ -64,6 +64,6 @@ class CretonneLexer(RegexLexer):
 
 def setup(app):
     """Setup Sphinx extension."""
-    app.add_lexer('cton', CretonneLexer())
+    app.add_lexer('clif', CraneliftLexer())
 
     return {'version': '0.1'}

cranelift/docs/compare-llvm.rst

@@ -1,5 +1,5 @@
 *************************
-Cretonne compared to LLVM
+Cranelift compared to LLVM
 *************************
 
 `LLVM <https://llvm.org>`_ is a collection of compiler components implemented as
@@ -10,18 +10,18 @@ popular. `Chris Lattner's chapter about LLVM
 Applications <https://aosabook.org/en/index.html>`_ book gives an excellent
 overview of the architecture and design of LLVM.
 
-Cretonne and LLVM are superficially similar projects, so it is worth
+Cranelift and LLVM are superficially similar projects, so it is worth
 highlighting some of the differences and similarities. Both projects:
 
 - Use an ISA-agnostic input language in order to mostly abstract away the
   differences between target instruction set architectures.
 - Depend extensively on SSA form.
 - Have both textual and in-memory forms of their primary intermediate
-  representation. (LLVM also has a binary bitcode format; Cretonne doesn't.)
+  representation. (LLVM also has a binary bitcode format; Cranelift doesn't.)
 - Can target multiple ISAs.
 - Can cross-compile by default without rebuilding the code generator.
 
-Cretonne's scope is much smaller than that of LLVM. The classical three main
+Cranelift's scope is much smaller than that of LLVM. The classical three main
 parts of a compiler are:
 
 1. The language-dependent front end parses and type-checks the input program.
@@ -29,9 +29,9 @@ parts of a compiler are:
    target ISA.
 3. The code generator which depends strongly on the target ISA.
 
-LLVM provides both common optimizations *and* a code generator. Cretonne only
+LLVM provides both common optimizations *and* a code generator. Cranelift only
 provides the last part, the code generator. LLVM additionally provides
-infrastructure for building assemblers and disassemblers. Cretonne does not
+infrastructure for building assemblers and disassemblers. Cranelift does not
 handle assembly at all---it only generates binary machine code.
 
 Intermediate representations
@@ -89,20 +89,20 @@ representation. Some target ISAs have a fast instruction selector that can
 translate simple code directly to MachineInstrs, bypassing SelectionDAG when
 possible.
 
-:doc:`Cretonne <langref>` uses a single intermediate representation to cover
+:doc:`Cranelift <langref>` uses a single intermediate representation to cover
-these levels of abstraction. This is possible in part because of Cretonne's
+these levels of abstraction. This is possible in part because of Cranelift's
 smaller scope.
 
-- Cretonne does not provide assemblers and disassemblers, so it is not
+- Cranelift does not provide assemblers and disassemblers, so it is not
   necessary to be able to represent every weird instruction in an ISA. Only
   those instructions that the code generator emits have a representation.
-- Cretonne's opcodes are ISA-agnostic, but after legalization / instruction
+- Cranelift's opcodes are ISA-agnostic, but after legalization / instruction
   selection, each instruction is annotated with an ISA-specific encoding which
   represents a native instruction.
 - SSA form is preserved throughout. After register allocation, each SSA value
   is annotated with an assigned ISA register or stack slot.
 
-The Cretonne intermediate representation is similar to LLVM IR, but at a slightly
+The Cranelift intermediate representation is similar to LLVM IR, but at a slightly
 lower level of abstraction.
 
 Program structure
@@ -112,22 +112,22 @@ In LLVM IR, the largest representable unit is the *module* which corresponds
 more or less to a C translation unit. It is a collection of functions and
 global variables that may contain references to external symbols too.
 
-In Cretonne IR, the largest representable unit is the *function*. This is so
+In Cranelift IR, the largest representable unit is the *function*. This is so
 that functions can easily be compiled in parallel without worrying about
-references to shared data structures. Cretonne does not have any
+references to shared data structures. Cranelift does not have any
 inter-procedural optimizations like inlining.
 
-An LLVM IR function is a graph of *basic blocks*. A Cretonne IR function is a
+An LLVM IR function is a graph of *basic blocks*. A Cranelift IR function is a
 graph of *extended basic blocks* that may contain internal branch instructions.
 The main difference is that an LLVM conditional branch instruction has two
-target basic blocks---a true and a false edge. A Cretonne branch instruction
+target basic blocks---a true and a false edge. A Cranelift branch instruction
 only has a single target and falls through to the next instruction when its
-condition is false. The Cretonne representation is closer to how machine code
+condition is false. The Cranelift representation is closer to how machine code
 works; LLVM's representation is more abstract.
 
 LLVM uses `phi instructions
 <https://llvm.org/docs/LangRef.html#phi-instruction>`_ in its SSA
-representation. Cretonne passes arguments to EBBs instead. The two
+representation. Cranelift passes arguments to EBBs instead. The two
 representations are equivalent, but the EBB arguments are better suited to
 handle EBBs that may contain multiple branches to the same destination block
 with different arguments. Passing arguments to an EBB looks a lot like passing
@@ -137,42 +137,42 @@ similarly. Arguments are assigned to registers or stack locations.
 Value types
 -----------
 
-:ref:`Cretonne's type system <value-types>` is mostly a subset of LLVM's type
+:ref:`Cranelift's type system <value-types>` is mostly a subset of LLVM's type
 system. It is less abstract and closer to the types that common ISA registers
 can hold.
 
-- Integer types are limited to powers of two from :cton:type:`i8` to
+- Integer types are limited to powers of two from :clif:type:`i8` to
-  :cton:type:`i64`. LLVM can represent integer types of arbitrary bit width.
+  :clif:type:`i64`. LLVM can represent integer types of arbitrary bit width.
-- Floating point types are limited to :cton:type:`f32` and :cton:type:`f64`
+- Floating point types are limited to :clif:type:`f32` and :clif:type:`f64`
   which is what WebAssembly provides. It is possible that 16-bit and 128-bit
   types will be added in the future.
-- Addresses are represented as integers---There are no Cretonne pointer types.
+- Addresses are represented as integers---There are no Cranelift pointer types.
   LLVM currently has rich pointer types that include the pointee type. It may
-  move to a simpler 'address' type in the future. Cretonne may add a single
+  move to a simpler 'address' type in the future. Cranelift may add a single
   address type too.
 - SIMD vector types are limited to a power-of-two number of vector lanes up to
   256. LLVM allows an arbitrary number of SIMD lanes.
-- Cretonne has no aggregate types. LLVM has named and anonymous struct types as
+- Cranelift has no aggregate types. LLVM has named and anonymous struct types as
   well as array types.
 
-Cretonne has multiple boolean types, whereas LLVM simply uses `i1`. The sized
+Cranelift has multiple boolean types, whereas LLVM simply uses `i1`. The sized
-Cretonne boolean types are used to represent SIMD vector masks like ``b32x4``
+Cranelift boolean types are used to represent SIMD vector masks like ``b32x4``
 where each lane is either all 0 or all 1 bits.
 
-Cretonne instructions and function calls can return multiple result values. LLVM
+Cranelift instructions and function calls can return multiple result values. LLVM
 instead models this by returning a single value of an aggregate type.
 
 Instruction set
 ---------------
 
 LLVM has a small well-defined basic instruction set and a large number of
-intrinsics, some of which are ISA-specific. Cretonne has a larger instruction
+intrinsics, some of which are ISA-specific. Cranelift has a larger instruction
-set and no intrinsics. Some Cretonne instructions are ISA-specific.
+set and no intrinsics. Some Cranelift instructions are ISA-specific.
 
-Since Cretonne instructions are used all the way until the binary machine code
+Since Cranelift instructions are used all the way until the binary machine code
 is emitted, there are opcodes for every native instruction that can be
 generated. There is a lot of overlap between different ISAs, so for example the
-:cton:inst:`iadd_imm` instruction is used by every ISA that can add an
+:clif:inst:`iadd_imm` instruction is used by every ISA that can add an
 immediate integer to a register. A simple RISC ISA like RISC-V can be defined
 with only shared instructions, while x86 needs a number of specific
 instructions to model addressing modes.
@@ -180,20 +180,20 @@ instructions to model addressing modes.
 Undefined behavior
 ==================
 
-Cretonne does not generally exploit undefined behavior in its optimizations.
+Cranelift does not generally exploit undefined behavior in its optimizations.
 LLVM's mid-level optimizations do, but it should be noted that LLVM's low-level code
 generator rarely needs to make use of undefined behavior either.
 
 LLVM provides ``nsw`` and ``nuw`` flags for its arithmetic that invoke
-undefined behavior on overflow. Cretonne does not provide this functionality.
+undefined behavior on overflow. Cranelift does not provide this functionality.
 Its arithmetic instructions either produce a value or a trap.
 
 LLVM has an ``unreachable`` instruction which is used to indicate impossible
-code paths. Cretonne only has an explicit :cton:inst:`trap` instruction.
+code paths. Cranelift only has an explicit :clif:inst:`trap` instruction.
 
-Cretonne does make assumptions about aliasing. For example, it assumes that it
+Cranelift does make assumptions about aliasing. For example, it assumes that it
 has full control of the stack objects in a function, and that they can only be
 modified by function calls if their address have escaped. It is quite likely
-that Cretonne will admit more detailed aliasing annotations on load/store
+that Cranelift will admit more detailed aliasing annotations on load/store
 instructions in the future. When these annotations are incorrect, undefined
 behavior ensues.

cranelift/docs/conf.py

@@ -1,6 +1,6 @@
 # -*- coding: utf-8 -*-
 #
-# cretonne documentation build configuration file, created by
+# cranelift documentation build configuration file, created by
 # sphinx-quickstart on Fri Mar  2 12:49:24 2018.
 #
 # This file is execfile()d with the current directory set to its
@@ -21,7 +21,7 @@ import os
 import sys
 sys.path.insert(0, os.path.abspath('.'))
 
-# Also add the meta directory to sys.path so autodoc can find the Cretonne meta
+# Also add the meta directory to sys.path so autodoc can find the Cranelift meta
 # language definitions.
 sys.path.insert(0, os.path.abspath('../lib/codegen/meta'))
 
@@ -41,8 +41,8 @@ extensions = [
     'sphinx.ext.ifconfig',
     'sphinx.ext.graphviz',
     'sphinx.ext.inheritance_diagram',
-    'cton_domain',
+    'clif_domain',
-    'cton_lexer',
+    'clif_lexer',
 ]
 
 # Add any paths that contain templates here, relative to this directory.
@@ -58,9 +58,9 @@ source_suffix = '.rst'
 master_doc = 'index'
 
 # General information about the project.
-project = u'cretonne'
+project = u'cranelift'
-copyright = u'2018, Cretonne Developers'
+copyright = u'2018, Cranelift Developers'
-author = u'Cretonne Developers'
+author = u'Cranelift Developers'
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
@@ -113,7 +113,7 @@ html_theme = 'sphinx_rtd_theme'
 # -- Options for HTMLHelp output ------------------------------------------
 
 # Output file base name for HTML help builder.
-htmlhelp_basename = 'cretonnedoc'
+htmlhelp_basename = 'craneliftdoc'
 
 
 # -- Options for LaTeX output ---------------------------------------------
@@ -140,7 +140,7 @@ latex_elements = {
 # (source start file, target name, title,
 #  author, documentclass [howto, manual, or own class]).
 latex_documents = [
-    (master_doc, 'cretonne.tex', u'cretonne Documentation',
+    (master_doc, 'cranelift.tex', u'cranelift Documentation',
      author, 'manual'),
 ]
 
@@ -150,7 +150,7 @@ latex_documents = [
 # One entry per manual page. List of tuples
 # (source start file, name, description, authors, manual section).
 man_pages = [
-    (master_doc, 'cretonne', u'cretonne Documentation',
+    (master_doc, 'cranelift', u'cranelift Documentation',
      [author], 1)
 ]
 
@@ -161,8 +161,8 @@ man_pages = [
 # (source start file, target name, title, author,
 #  dir menu entry, description, category)
 texinfo_documents = [
-    (master_doc, 'cretonne', u'cretonne Documentation',
+    (master_doc, 'cranelift', u'cranelift Documentation',
-     author, 'cretonne', 'One line description of project.',
+     author, 'cranelift', 'One line description of project.',
      'Miscellaneous'),
 ]
 

cranelift/docs/index.rst

@@ -1,4 +1,4 @@
-Cretonne Code Generator
+Cranelift Code Generator
 =======================
 
 Contents:
@@ -15,36 +15,36 @@ Contents:
 Rust Crate Documentation
 ========================
 
-`cretonne <https://docs.rs/cretonne/>`_
+`cranelift <https://docs.rs/cranelift/>`_
-    This is the core code generator crate. It takes Cretonne IR as input
+    This is the core code generator crate. It takes Cranelift IR as input
     and emits encoded machine instructions, along with symbolic relocations,
     as output.
 
-`cretonne-wasm <https://docs.rs/cretonne-wasm/>`_
+`cranelift-wasm <https://docs.rs/cranelift-wasm/>`_
-    This crate translates WebAssembly code into Cretonne IR.
+    This crate translates WebAssembly code into Cranelift IR.
 
-`cretonne-frontend <https://docs.rs/cretonne-frontend/>`_
+`cranelift-frontend <https://docs.rs/cranelift-frontend/>`_
-    This crate provides utilities for translating code into Cretonne IR.
+    This crate provides utilities for translating code into Cranelift IR.
 
-`cretonne-native <https://docs.rs/cretonne-native/>`_
+`cranelift-native <https://docs.rs/cranelift-native/>`_
-    This crate performs auto-detection of the host, allowing Cretonne to
+    This crate performs auto-detection of the host, allowing Cranelift to
     generate code optimized for the machine it's running on.
 
-`cretonne-reader <https://docs.rs/cretonne-reader/>`_
+`cranelift-reader <https://docs.rs/cranelift-reader/>`_
-    This crate translates from Cretonne IR's text format into Cretonne IR
+    This crate translates from Cranelift IR's text format into Cranelift IR
     in in-memory data structures.
 
-`cretonne-module <https://docs.rs/cretonne-module/>`_
+`cranelift-module <https://docs.rs/cranelift-module/>`_
     This crate manages compiling multiple functions and data objects
     together.
 
-`cretonne-faerie <https://docs.rs/cretonne-faerie/>`_
+`cranelift-faerie <https://docs.rs/cranelift-faerie/>`_
-    This crate provides a faerie-based backend for `cretonne-module`, which
+    This crate provides a faerie-based backend for `cranelift-module`, which
     emits native object files using the
     `faerie <https://crates.io/crates/faerie/>`_ library.
 
-`cretonne-simplejit <https://docs.rs/cretonne-simplejit/>`_
+`cranelift-simplejit <https://docs.rs/cranelift-simplejit/>`_
-    This crate provides a simple JIT backend for `cretonne-module`, which
+    This crate provides a simple JIT backend for `cranelift-module`, which
     emits code and data into memory.
 
 Indices and tables

cranelift/docs/langref.rst

@@ -1,14 +1,14 @@
 ***************************
-Cretonne Language Reference
+Cranelift Language Reference
 ***************************
 
-.. default-domain:: cton
+.. default-domain:: clif
-.. highlight:: cton
+.. highlight:: clif
 
-The Cretonne intermediate representation (:term:`IR`) has two primary forms:
+The Cranelift intermediate representation (:term:`IR`) has two primary forms:
 an *in-memory data structure* that the code generator library is using, and a
 *text format* which is used for test cases and debug output.
-Files containing Cretonne textual IR have the ``.cton`` filename extension.
+Files containing Cranelift textual IR have the ``.clif`` filename extension.
 
 This reference uses the text format to describe IR semantics but glosses over
 the finer details of the lexical and syntactic structure of the format.
@@ -17,7 +17,7 @@ the finer details of the lexical and syntactic structure of the format.
 Overall structure
 =================
 
-Cretonne compiles functions independently. A ``.cton`` IR file may contain
+Cranelift compiles functions independently. A ``.clif`` IR file may contain
 multiple functions, and the programmatic API can create multiple function
 handles at the same time, but the functions don't share any data or reference
 each other directly.
@@ -27,10 +27,10 @@ This is a simple C function that computes the average of an array of floats:
 .. literalinclude:: example.c
     :language: c
 
-Here is the same function compiled into Cretonne IR:
+Here is the same function compiled into Cranelift IR:
 
-.. literalinclude:: example.cton
+.. literalinclude:: example.clif
-    :language: cton
+    :language: clif
     :lines: 2-
 
 The first line of a function definition provides the function *name* and
@@ -44,7 +44,7 @@ After the preamble follows the :term:`function body` which consists of
 :term:`entry block`. Every EBB ends with a :term:`terminator instruction`, so
 execution can never fall through to the next EBB without an explicit branch.
 
-A ``.cton`` file consists of a sequence of independent function definitions:
+A ``.clif`` file consists of a sequence of independent function definitions:
 
 .. productionlist::
     function_list : { function }
@@ -59,7 +59,7 @@ The instructions in the function body use and produce *values* in SSA form. This
 means that every value is defined exactly once, and every use of a value must be
 dominated by the definition.
 
-Cretonne does not have phi instructions but uses :term:`EBB parameter`\s
+Cranelift does not have phi instructions but uses :term:`EBB parameter`\s
 instead. An EBB can be defined with a list of typed parameters. Whenever control
 is transferred to the EBB, argument values for the parameters must be provided.
 When entering a function, the incoming function parameters are passed as
@@ -74,11 +74,11 @@ SSA values: In the entry block, ``v4`` is the initial value. In the loop block
 variable during each iteration. Finally, ``v12`` is computed as the induction
 variable value for the next iteration.
 
-The `cretonne_frontend` crate contains utilities for translating from programs
+The `cranelift_frontend` crate contains utilities for translating from programs
 containing multiple assignments to the same variables into SSA form for
-Cretonne :term:`IR`.
+Cranelift :term:`IR`.
 
-Such variables can also be presented to Cretonne as :term:`stack slot`\s.
+Such variables can also be presented to Cranelift as :term:`stack slot`\s.
 Stack slots are accessed with the :inst:`stack_store` and :inst:`stack_load`
 instructions, and can have their address taken with :inst:`stack_addr`, which
 supports C-like programming languages where local variables can have their
@@ -103,11 +103,11 @@ value. It can only exist as an SSA value, it can't be stored in memory or
 converted to another type. The larger boolean types can be stored in memory.
 They are represented as either all zero bits or all one bits.
 
-.. autoctontype:: b1
+.. autocliftype:: b1
-.. autoctontype:: b8
+.. autocliftype:: b8
-.. autoctontype:: b16
+.. autocliftype:: b16
-.. autoctontype:: b32
+.. autocliftype:: b32
-.. autoctontype:: b64
+.. autocliftype:: b64
 
 Integer types
 -------------
@@ -118,10 +118,10 @@ number, others don't care.
 
 The support for i8 and i16 arithmetic is incomplete and use could lead to bugs.
 
-.. autoctontype:: i8
+.. autocliftype:: i8
-.. autoctontype:: i16
+.. autocliftype:: i16
-.. autoctontype:: i32
+.. autocliftype:: i32
-.. autoctontype:: i64
+.. autocliftype:: i64
 
 Floating point types
 --------------------
@@ -149,8 +149,8 @@ instructions are encoded as follows:
   and all bits of the trailing significand other than the MSB set to
   nondeterministic values.
 
-.. autoctontype:: f32
+.. autocliftype:: f32
-.. autoctontype:: f64
+.. autocliftype:: f64
 
 CPU flags types
 ---------------
@@ -168,8 +168,8 @@ live at the same time. After legalization, some instruction encodings will
 clobber the flags, and flags values are not allowed to be live across such
 instructions either. The verifier enforces these rules.
 
-.. autoctontype:: iflags
+.. autocliftype:: iflags
-.. autoctontype:: fflags
+.. autocliftype:: fflags
 
 SIMD vector types
 -----------------
@@ -420,7 +420,7 @@ baldrdash  SpiderMonkey WebAssembly convention
 ========== ===========================================
 
 The "not-ABI-stable" conventions do not follow an external specification and
-may change between versions of Cretonne.
+may change between versions of Cranelift.
 
 The "fastcall" convention is not yet implemented.
 
@@ -448,8 +448,8 @@ preamble`:
 
 This simple example illustrates direct function calls and signatures:
 
-.. literalinclude:: callex.cton
+.. literalinclude:: callex.clif
-    :language: cton
+    :language: clif
     :lines: 3-
 
 Indirect function calls use a signature declared in the preamble.
@@ -462,7 +462,7 @@ Indirect function calls use a signature declared in the preamble.
 Memory
 ======
 
-Cretonne provides fully general :inst:`load` and :inst:`store` instructions for
+Cranelift provides fully general :inst:`load` and :inst:`store` instructions for
 accessing memory, as well as :ref:`extending loads and truncating stores
 <extload-truncstore>`.
 
@@ -515,7 +515,7 @@ frame.
 
     Allocate a stack slot in the preamble.
 
-    If no alignment is specified, Cretonne will pick an appropriate alignment
+    If no alignment is specified, Cranelift will pick an appropriate alignment
     for the stack slot based on its size and access patterns.
 
     :arg Bytes: Stack slot size on bytes.
@@ -543,7 +543,7 @@ instructions before instruction selection::
     v1 = stack_addr ss3, 16
     v0 = load.f64 v1
 
-When Cretonne code is running in a sandbox, it can also be necessary to include
+When Cranelift code is running in a sandbox, it can also be necessary to include
 stack overflow checks in the prologue.
 
 .. inst:: stack_limit = GV
@@ -564,14 +564,14 @@ A *global value* is an object whose value is not known at compile time. The
 value is computed at runtime by :inst:`global_value`, possibly using
 information provided by the linker via relocations. There are multiple
 kinds of global values using different methods for determining their value.
-Cretonne does not track the type of a global value, for they are just
+Cranelift does not track the type of a global value, for they are just
 values stored in non-stack memory.
 
-When Cretonne is generating code for a virtual machine environment, globals can
+When Cranelift is generating code for a virtual machine environment, globals can
 be used to access data structures in the VM's runtime. This requires functions
 to have access to a *VM context pointer* which is used as the base address.
 Typically, the VM context pointer is passed as a hidden function argument to
-Cretonne functions.
+Cranelift functions.
 
 .. inst:: GV = vmctx+Offset
 
@@ -632,7 +632,7 @@ Heaps
 
 Code compiled from WebAssembly or asm.js runs in a sandbox where it can't access
 all process memory. Instead, it is given a small set of memory areas to work
-in, and all accesses are bounds checked. Cretonne models this through the
+in, and all accesses are bounds checked. Cranelift models this through the
 concept of *heaps*.
 
 A heap is declared in the function preamble and can be accessed with the
@@ -727,16 +727,16 @@ guard pages when running WebAssembly code on 64-bit CPUs. The combination of a
 4 GB fixed bound and 1-byte bounds checks means that no code needs to be
 generated for bounds checks at all:
 
-.. literalinclude:: heapex-sm64.cton
+.. literalinclude:: heapex-sm64.clif
-    :language: cton
+    :language: clif
     :lines: 2-
 
 A static heap can also be used for 32-bit code when the WebAssembly module
 declares a small upper bound on its memory. A 1 MB static bound with a single 4
 KB guard page still has opportunities for sharing bounds checking code:
 
-.. literalinclude:: heapex-sm32.cton
+.. literalinclude:: heapex-sm32.clif
-    :language: cton
+    :language: clif
     :lines: 2-
 
 If the upper bound on the heap size is too large, a dynamic heap is required
@@ -746,8 +746,8 @@ Finally, a runtime environment that simply allocates a heap with
 :c:func:`malloc()` may not have any guard pages at all. In that case, full
 bounds checking is required for each access:
 
-.. literalinclude:: heapex-dyn.cton
+.. literalinclude:: heapex-dyn.clif
-    :language: cton
+    :language: clif
     :lines: 2-
 
 
@@ -772,7 +772,7 @@ load a constant into an SSA value.
 Live range splitting
 --------------------
 
-Cretonne's register allocator assigns each SSA value to a register or a spill
+Cranelift's register allocator assigns each SSA value to a register or a spill
 slot on the stack for its entire live range. Since the live range of an SSA
 value can be quite large, it is sometimes beneficial to split the live range
 into smaller parts.
@@ -1014,7 +1014,7 @@ Most ISAs provide instructions that load an integer value smaller than a registe
 and extends it to the width of the register. Similarly, store instructions that
 only write the low bits of an integer register are common.
 
-In addition to the normal :inst:`load` and :inst:`store` instructions, Cretonne
+In addition to the normal :inst:`load` and :inst:`store` instructions, Cranelift
 provides extending loads and truncation stores for 8, 16, and 32-bit memory
 accesses.
 
@@ -1067,7 +1067,7 @@ Target ISAs may define further instructions in their own instruction groups:
 Implementation limits
 =====================
 
-Cretonne's intermediate representation imposes some limits on the size of
+Cranelift's intermediate representation imposes some limits on the size of
 functions and the number of entities allowed. If these limits are exceeded, the
 implementation will panic.
 
@@ -1098,7 +1098,7 @@ Number of arguments to a function
     At most :math:`2^{16}`.
 
     This follows from the limit on arguments to the entry EBB. Note that
-    Cretonne may add a handful of ABI register arguments as function signatures
+    Cranelift may add a handful of ABI register arguments as function signatures
     are lowered. This is for representing things like the link register, the
     incoming frame pointer, and callee-saved registers that are saved in the
     prologue.
@@ -1134,7 +1134,7 @@ Glossary
 
     entry block
         The :term:`EBB` that is executed first in a function. Currently, a
-        Cretonne function must have exactly one entry block which must be the
+        Cranelift function must have exactly one entry block which must be the
         first block in the function. The types of the entry block arguments must
         match the types of arguments in the function signature.
 
@@ -1152,7 +1152,7 @@ Glossary
 
         Note that some textbooks define an EBB as a maximal *subtree* in the
         control flow graph where only the root can be a join node. This
-        definition is not equivalent to Cretonne EBBs.
+        definition is not equivalent to Cranelift EBBs.
 
     EBB parameter
         A formal parameter for an EBB is an SSA value that dominates everything
@@ -1195,8 +1195,8 @@ Glossary
 
     intermediate representation
     IR
-        The language used to describe functions to Cretonne. This reference
+        The language used to describe functions to Cranelift. This reference
-        describes the syntax and semantics of Cretonne IR. The IR has two
+        describes the syntax and semantics of Cranelift IR. The IR has two
         forms: Textual, and an in-memory data structure.
 
     stack slot

cranelift/docs/make.bat

@@ -9,7 +9,7 @@ if "%SPHINXBUILD%" == "" (
 )
 set SOURCEDIR=.
 set BUILDDIR=_build
-set SPHINXPROJ=cretonne
+set SPHINXPROJ=cranelift
 
 if "%1" == "" goto help
 

cranelift/docs/metaref.rst

@@ -1,12 +1,12 @@
 ********************************
-Cretonne Meta Language Reference
+Cranelift Meta Language Reference
 ********************************
 
 .. default-domain:: py
 .. highlight:: python
 .. module:: cdsl
 
-The Cretonne meta language is used to define instructions for Cretonne. It is a
+The Cranelift meta language is used to define instructions for Cranelift. It is a
 domain specific language embedded in Python. This document describes the Python
 modules that form the embedded DSL.
 
@@ -33,7 +33,7 @@ since the last build.
 Settings
 ========
 
-Settings are used by the environment embedding Cretonne to control the details
+Settings are used by the environment embedding Cranelift to control the details
 of code generation. Each setting is defined in the meta language so a compact
 and consistent Rust representation can be generated. Shared settings are defined
 in the :mod:`base.settings` module. Some settings are specific to a target ISA,
@@ -80,7 +80,7 @@ open :class:`InstructionGroup`.
 .. autoclass:: InstructionGroup
     :members:
 
-The basic Cretonne instruction set described in :doc:`langref` is defined by the
+The basic Cranelift instruction set described in :doc:`langref` is defined by the
 Python module :mod:`base.instructions`. This module has a global value
 :data:`base.instructions.GROUP` which is an :class:`InstructionGroup` instance
 containing all the base instructions.
@@ -94,7 +94,7 @@ must be instances of the :class:`Operand` class.
 
 .. autoclass:: Operand
 
-Cretonne uses two separate type systems for operand kinds and SSA values.
+Cranelift uses two separate type systems for operand kinds and SSA values.
 
 .. module:: cdsl.typevar
 
@@ -191,7 +191,7 @@ Instruction representation
 
 The Rust in-memory representation of instructions is derived from the
 instruction descriptions. Part of the representation is generated, and part is
-written as Rust code in the ``cretonne.instructions`` module. The instruction
+written as Rust code in the ``cranelift.instructions`` module. The instruction
 representation depends on the input operand kinds and whether the instruction
 can produce multiple results.
 
@@ -259,9 +259,9 @@ Encodings
 
 .. currentmodule:: cdsl.isa
 
-Encodings describe how Cretonne instructions are mapped to binary machine code
+Encodings describe how Cranelift instructions are mapped to binary machine code
 for the target architecture. After the legalization pass, all remaining
-instructions are expected to map 1-1 to native instruction encodings. Cretonne
+instructions are expected to map 1-1 to native instruction encodings. Cranelift
 instructions that can't be encoded for the current architecture are called
 :term:`illegal instruction`\s.
 
@@ -270,7 +270,7 @@ incompatible encodings. For example, a modern ARMv8 CPU might support three
 different CPU modes: *A64* where instructions are encoded in 32 bits, *A32*
 where all instructions are 32 bits, and *T32* which has a mix of 16-bit and
 32-bit instruction encodings. These are incompatible encoding spaces, and while
-an :cton:inst:`iadd` instruction can be encoded in 32 bits in each of them, it's
+an :clif:inst:`iadd` instruction can be encoded in 32 bits in each of them, it's
 not the same 32 bits. It's a judgement call if CPU modes should be modelled as
 separate targets, or as sub-modes of the same target. In the ARMv8 case, the
 different register banks means that it makes sense to model A64 as a separate
@@ -293,7 +293,7 @@ is false, the SSE 4.1 instructions are not available.
 Encodings also have a :term:`instruction predicate` which depends on the
 specific values of the instruction's immediate fields. This is used to ensure
 that immediate address offsets are within range, for example. The instructions
-in the base Cretonne instruction set can often represent a wider range of
+in the base Cranelift instruction set can often represent a wider range of
 immediates than any specific encoding. The fixed-size RISC-style encodings tend
 to have more range limitations than CISC-style variable length encodings like
 x86.
@@ -320,7 +320,7 @@ An :py:class:`Encoding` instance specifies the encoding of a concrete
 instruction. The following properties are used to select instructions to be
 encoded:
 
-- An opcode, i.e. :cton:inst:`iadd_imm`, that must match the instruction's
+- An opcode, i.e. :clif:inst:`iadd_imm`, that must match the instruction's
   opcode.
 - Values for any type variables if the opcode represents a polymorphic
   instruction.
@@ -412,8 +412,8 @@ class which consists of all the XMM registers.
 Stack operands
 --------------
 
-Cretonne's register allocator can assign an SSA value to a stack slot if there
+Cranelift's register allocator can assign an SSA value to a stack slot if there
-isn't enough registers. It will insert :cton:inst:`spill` and :cton:inst:`fill`
+isn't enough registers. It will insert :clif:inst:`spill` and :clif:inst:`fill`
 instructions as needed to satisfy instruction operand constraints, but it is
 also possible to have instructions that can access stack slots directly::
 
@@ -427,7 +427,7 @@ load.
 Targets
 =======
 
-Cretonne can be compiled with support for multiple target instruction set
+Cranelift can be compiled with support for multiple target instruction set
 architectures. Each ISA is represented by a :py:class:`cdsl.isa.TargetISA` instance.
 
 .. autoclass:: TargetISA

cranelift/docs/regalloc.rst

@@ -1,11 +1,11 @@
 *******************************
-Register Allocation in Cretonne
+Register Allocation in Cranelift
 *******************************
 
-.. default-domain:: cton
+.. default-domain:: clif
-.. highlight:: cton
+.. highlight:: clif
 
-Cretonne uses a *decoupled, SSA-based* register allocator. Decoupled means that
+Cranelift uses a *decoupled, SSA-based* register allocator. Decoupled means that
 register allocation is split into two primary phases: *spilling* and
 *coloring*. SSA-based means that the code stays in SSA form throughout the
 register allocator, and in fact is still in SSA form after register allocation.
@@ -162,13 +162,13 @@ linearly with the number of EBBs covered by a live range.
 This representation is very similar to LLVM's ``LiveInterval`` data structure
 with a few important differences:
 
-- The Cretonne ``LiveRange`` only covers a single SSA value, while LLVM's
+- The Cranelift ``LiveRange`` only covers a single SSA value, while LLVM's
   ``LiveInterval`` represents the union of multiple related SSA values in a
-  virtual register. This makes Cretonne's representation smaller because
+  virtual register. This makes Cranelift's representation smaller because
   individual segments don't have to annotated with a value number.
-- Cretonne stores the def-interval separately from a list of coalesced live-in
+- Cranelift stores the def-interval separately from a list of coalesced live-in
   intervals, while LLVM stores an array of segments. The two representations
-  are equivalent, but Cretonne optimizes for the common case of a value that is
+  are equivalent, but Cranelift optimizes for the common case of a value that is
   only used locally.
 - It is simpler to check if two live ranges are overlapping. The dominance
   properties of SSA form means that it is only necessary to check the
@@ -182,12 +182,12 @@ with a few important differences:
   allows 'tombstone' program points corresponding to instructions that have
   been deleted.
 
-  Cretonne uses a 32-bit program point representation that encodes an
+  Cranelift uses a 32-bit program point representation that encodes an
   instruction or EBB number directly. There are no 'tombstones' for deleted
   instructions, and no mirrored linked list of instructions. Live ranges must
   be updated when instructions are deleted.
 
-A consequence of Cretonne's more compact representation is that two program
+A consequence of Cranelift's more compact representation is that two program
 points can't be compared without the context of a function layout.
 
 Coalescing algorithm
@@ -273,7 +273,7 @@ extra registers to solve, raising the register pressure:
   the tied input value doesn't interfere with the output value by inserting a copy
   if needed.
 
-The spilling heuristic used by Cretonne is very simple. Whenever the spiller
+The spilling heuristic used by Cranelift is very simple. Whenever the spiller
 determines that the register pressure is too high at some instruction, it picks
 the live SSA value whose definition is farthest away as the spill candidate.
 Then it spills all values in the corresponding virtual register to the same

cranelift/docs/testing.rst

@@ -1,21 +1,21 @@
 ****************
-Testing Cretonne
+Testing Cranelift
 ****************
 
-Cretonne is tested at multiple levels of abstraction and integration. When
+Cranelift is tested at multiple levels of abstraction and integration. When
 possible, Rust unit tests are used to verify single functions and types. When
 testing the interaction between compiler passes, file-level tests are
 appropriate.
 
 The top-level shell script :file:`test-all.sh` runs all of the tests in the
-Cretonne repository.
+Cranelift repository.
 
 Rust tests
 ==========
 
 .. highlight:: rust
 
-Rust and Cargo have good support for testing. Cretonne uses unit tests, doc
+Rust and Cargo have good support for testing. Cranelift uses unit tests, doc
 tests, and integration tests where appropriate.
 
 Unit tests
@@ -51,7 +51,7 @@ tested::
     //!
     //! # Example
     //! ```
-    //! use cretonne_codegen::settings::{self, Configurable};
+    //! use cranelift_codegen::settings::{self, Configurable};
     //!
     //! let mut b = settings::builder();
     //! b.set("opt_level", "fastest");
@@ -72,7 +72,7 @@ individually. They are used to exercise the external API of the crates under
 test.
 
 These tests are usually found in the :file:`tests` top-level directory where
-they have access to all the crates in the Cretonne repository. The
+they have access to all the crates in the Cranelift repository. The
 :file:`lib/codegen` and :file:`lib/reader` crates have no external
 dependencies, which can make testing tedious. Integration tests that don't need
 to depend on other crates can be placed in :file:`lib/codegen/tests` and
@@ -81,15 +81,15 @@ to depend on other crates can be placed in :file:`lib/codegen/tests` and
 File tests
 ==========
 
-.. highlight:: cton
+.. highlight:: clif
 
 Compilers work with large data structures representing programs, and it quickly
 gets unwieldy to generate test data programmatically. File-level tests make it
 easier to provide substantial input functions for the compiler tests.
 
-File tests are :file:`*.cton` files in the :file:`filetests/` directory
+File tests are :file:`*.clif` files in the :file:`filetests/` directory
 hierarchy. Each file has a header describing what to test followed by a number
-of input functions in the :doc:`Cretonne textual intermediate representation
+of input functions in the :doc:`Cranelift textual intermediate representation
 <langref>`:
 
 .. productionlist::
@@ -111,7 +111,7 @@ header:
 The options given on the ``isa`` line modify the ISA-specific settings defined in
 :file:`lib/codegen/meta/isa/*/settings.py`.
 
-All types of tests allow shared Cretonne settings to be modified:
+All types of tests allow shared Cranelift settings to be modified:
 
 .. productionlist::
     settings      : { setting }
@@ -137,7 +137,7 @@ This example will run the legalizer test twice. Both runs will have
 run will also have the RISC-V specific flag ``supports_m`` disabled.
 
 The filetests are run automatically as part of `cargo test`, and they can
-also be run manually with the `cton-util test` command.
+also be run manually with the `clif-util test` command.
 
 Filecheck
 ---------
@@ -146,7 +146,7 @@ Many of the test commands described below use *filecheck* to verify their
 output. Filecheck is a Rust implementation of the LLVM tool of the same name.
 See the `documentation <https://docs.rs/filecheck/>`_ for details of its syntax.
 
-Comments in :file:`.cton` files are associated with the entity they follow.
+Comments in :file:`.clif` files are associated with the entity they follow.
 This typically means an instruction or the whole function. Those tests that
 use filecheck will extract comments associated with each function (or its
 entities) and scan them for filecheck directives. The test output for each
@@ -160,7 +160,7 @@ Note that LLVM's file tests don't separate filecheck directives by their
 associated function. It verifies the concatenated output against all filecheck
 directives in the test file. LLVM's :command:`FileCheck` command has a
 ``CHECK-LABEL:`` directive to help separate the output from different functions.
-Cretonne's tests don't need this.
+Cranelift's tests don't need this.
 
 `test cat`
 ----------
@@ -214,7 +214,7 @@ function verifies correctly.
 ----------------
 
 Print the control flow graph of each function as a Graphviz graph, and run
-filecheck over the result. See also the :command:`cton-util print-cfg`
+filecheck over the result. See also the :command:`clif-util print-cfg`
 command::
 
     ; For testing cfg generation. This code is nonsense.
@@ -375,4 +375,4 @@ Each function is passed through the full ``Context::compile()`` function
 which is normally used to compile code. This type of test often depends
 on assertions or verifier errors, but it is also possible to use
 filecheck directives which will be matched against the final form of the
-Cretonne IR right before binary machine code emission.
+Cranelift IR right before binary machine code emission.

cranelift/filetests/isa/x86/allones_funcaddrs32.clif

@@ -6,10 +6,10 @@ target i686 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/allones_funcaddrs32.cton | llvm-mc -show-encoding -triple=i386
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/allones_funcaddrs32.clif | llvm-mc -show-encoding -triple=i386
 ;
 
-; Tests from binary32.cton affected by allones_funcaddrs.
+; Tests from binary32.clif affected by allones_funcaddrs.
 function %I32() {
     sig0 = ()
     fn0 = %foo()

cranelift/filetests/isa/x86/allones_funcaddrs64.clif

@@ -6,10 +6,10 @@ target x86_64 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/allones_funcaddrs64.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/allones_funcaddrs64.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
-; Tests from binary64.cton affected by allones_funcaddrs.
+; Tests from binary64.clif affected by allones_funcaddrs.
 function %I64() {
     sig0 = ()
     fn0 = %foo()

cranelift/filetests/isa/x86/baseline_clz_ctz_popcount_encoding.clif

@@ -4,7 +4,7 @@ target x86_64 baseline
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/baseline_clz_ctz_popcount_encoding.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/baseline_clz_ctz_popcount_encoding.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
 function %Foo() {

cranelift/filetests/isa/x86/binary32-float.clif

@@ -4,7 +4,7 @@ target i686 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary32-float.cton | llvm-mc -show-encoding -triple=i386
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary32-float.clif | llvm-mc -show-encoding -triple=i386
 ;
 
 function %F32() {

cranelift/filetests/isa/x86/binary32.clif

@@ -5,7 +5,7 @@ target i686 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary32.cton | llvm-mc -show-encoding -triple=i386
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary32.clif | llvm-mc -show-encoding -triple=i386
 ;
 
 function %I32() {

cranelift/filetests/isa/x86/binary64-float.clif

@@ -5,7 +5,7 @@ target x86_64 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary64-float.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary64-float.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
 function %F32() {

cranelift/filetests/isa/x86/binary64-pic.clif

@@ -6,7 +6,7 @@ target x86_64 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary64-pic.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary64-pic.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
 ; Tests for i64 instructions.

cranelift/filetests/isa/x86/binary64.clif

@@ -5,7 +5,7 @@ target x86_64 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary64.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/binary64.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
 ; Tests for i64 instructions.

cranelift/filetests/isa/x86/legalize-div-traps.clif

@@ -1,6 +1,6 @@
 ; Test the division legalizations.
 test legalizer
-; See also legalize-div.cton.
+; See also legalize-div.clif.
 set avoid_div_traps=1
 target x86_64
 

cranelift/filetests/isa/x86/legalize-div.clif

@@ -1,6 +1,6 @@
 ; Test the division legalizations.
 test legalizer
-; See also legalize-div-traps.cton.
+; See also legalize-div-traps.clif.
 set avoid_div_traps=0
 target x86_64
 

cranelift/filetests/isa/x86/probestack-adjusts-sp.clif

@@ -3,7 +3,7 @@ set colocated_libcalls=1
 set probestack_func_adjusts_sp=1
 target x86_64
 
-; Like %big in probestack.cton, but with the probestack function adjusting
+; Like %big in probestack.clif, but with the probestack function adjusting
 ; the stack pointer itself.
 
 function %big() system_v {

cranelift/filetests/isa/x86/probestack-disabled.clif

@@ -3,7 +3,7 @@ set colocated_libcalls=1
 set probestack_enabled=0
 target x86_64
 
-; Like %big in probestack.cton, but with probes disabled.
+; Like %big in probestack.clif, but with probes disabled.
 
 function %big() system_v {
     ss0 = explicit_slot 300000

cranelift/filetests/isa/x86/probestack-noncolocated.clif

@@ -1,7 +1,7 @@
 test compile
 target x86_64
 
-; Like %big in probestack.cton, but without a colocated libcall.
+; Like %big in probestack.clif, but without a colocated libcall.
 
 function %big() system_v {
     ss0 = explicit_slot 300000

cranelift/filetests/isa/x86/probestack-size.clif

@@ -3,7 +3,7 @@ set colocated_libcalls=1
 set probestack_size_log2=13
 target x86_64
 
-; Like %big in probestack.cton, but now the probestack size is bigger
+; Like %big in probestack.clif, but now the probestack size is bigger
 ; and it no longer needs a probe.
 
 function %big() system_v {

cranelift/filetests/isa/x86/shrink.clif

@@ -6,7 +6,7 @@ target x86_64
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/shrink.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/shrink.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
 function %test_shrinking(i32) -> i32 {

cranelift/filetests/isa/x86/stack-addr64.clif

@@ -5,7 +5,7 @@ target x86_64 haswell
 
 ; The binary encodings can be verified with the command:
 ;
-;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/stack-addr64.cton | llvm-mc -show-encoding -triple=x86_64
+;   sed -ne 's/^ *; asm: *//p' filetests/isa/x86/stack-addr64.clif | llvm-mc -show-encoding -triple=x86_64
 ;
 
 function %stack_addr() {