Elaborate on Cretonne's rustc backend goals. (#257)

* Elaborate on Cretonne's rustc backend goals.

* Remove these extra newlines. They don't show up in the rendered form anyway.

* Fix typo.

* The document is meant to speak with the voice of the project.

rustc.rst

@@ -2,15 +2,63 @@
 Cretonne in Rustc
 =================
 
-The Rust compiler currently uses LLVM as its optimizer and code generator for both debug and
-release builds. The Cretonne project does not intend to compete with LLVM when it comes to
-optimizing release builds, but for debug builds where compilation speed is paramount, it makes
-sense to use Cretonne instead of LLVM.
+One goal for Cretonne is to be usable as a backend suitable for compiling Rust
+in debug mode. This mode doesn't require a lot of mid-level optimization, and it
+does want very fast compile times, and this matches up fairly well with what we
+expect Cretonne's initial strengths and weaknesses will be. Cretonne is being
+designed to take aggressive advantage of multiple cores, and to be very efficient
+with its use of memory.
 
-- Cretonne is designed to take advantage of multi-core CPUs, making parallel code generation quite
-  easy. This is harder with LLVM which was designed before multi-core CPUs where mainstream.
-- Cretonne is designed with compilation speed in mind. It makes engineering tradeoffs that favor
-  compilation speed over advanced optimizations.
+Another goal is a "pretty good" backend. The idea here is to do the work to get
+MIR-level inlining enabled, do some basic optimizations in Cretonne to capture the
+low-hanging fruit, and then use that along with good low-level optimizations to
+produce code which has a chance of being decently fast, with quite fast compile
+times. It obviously wouldn't compete with LLVM-based release builds in terms of
+optimization, but for some users, completely unoptimized code is too slow to test
+with, so a "pretty good" mode might be good enough.
 
-See `the discussion on the Rust internals forum
-<https://internals.rust-lang.org/t/possible-alternative-compiler-backend-cretonne>`_.
+There's plenty of work to do to achieve these goals, and if achieve them, we'll have
+enabled a Rust compiler written entirely in Rust, and enabled faster Rust compile
+times for important use cases.
+
+With all that said, there is a potential goal beyond that, which is to build a
+full optimizing release-capable backend. We can't predict how far Cretonne will go
+yet, but we do have some crazy ideas about what such a thing might look like,
+including:
+
+- Take advantage of Rust language properties in the optimizer. With LLVM, Rust is
+  able to use annotations to describe some of its aliasing guarantees, however the
+  annotations are awkward and limited. An optimizer that can represent the core
+  aliasing relationships that Rust provides directly has the potential to be very
+  powerful without the need for complex alias analysis logic. Unsafe blocks are an
+  interesting challenge, however in many simple cases, like Vec, it may be possible
+  to recover what the optimizer needs to know.
+
+- Design for superoptimization. Traditionally, compiler development teams have
+  spent many years of manual effort to identify patterns of code that can be
+  matched and replaced. Superoptimizers have been contributing some to this
+  effort, but in the future, we may be able to reverse roles.
+  Superoptimizers will do the bulk of the work, and humans will contribute
+  specialized optimizations that superoptimizers miss. This has the potential to
+  take a new optimizer from scratch to diminishing-returns territory with much
+  less manual effort.
+
+- Build an optimizer IR without the constraints of fast-debug-build compilation.
+  Cretonne's base IR is focused on Codegen, so a full-strength optimizer would either
+  use an IR layer on top of it (possibly using Cretonne's flexible EntityMap system),
+  or possibly an independent IR that could be translated to/from the base IR. Either
+  way, this overall architecture would keep the optimizer out of the way of the
+  non-optimizing build path, which keeps that path fast and simple, and gives the
+  optimizer more flexibility. If we then want to base the IR on a powerful data
+  structure like the Value State Dependence Graph (VSDG), we can do so with fewer
+  compromises.
+
+And, these ideas build on each other. For example, one of the challenges for
+dependence-graph-oriented IRs like the VSDG is getting good enough memory dependence
+information. But if we can get high-quality aliasing information directly from the
+Rust front-end, we should be in great shape. As another example, it's often harder
+for superoptimizers to reason about control flow than expression graphs. But,
+graph-oriented IRs like the VSDG represent control flow as control dependencies.
+It's difficult to say how powerful this combination will be until we try it, but
+if nothing else, it should be very convenient to express pattern-matching over a
+single graph that includes both data and control dependencies.