1Cranelift in Rustc 2================== 3 4One goal for Cranelift is to be usable as a backend suitable for 5compiling Rust in debug mode. This mode doesn't require a lot of 6mid-level optimization, and it does want very fast compile times, and 7this matches up fairly well with what we expect Cranelift's initial 8strengths and weaknesses will be. Cranelift is being designed to take 9aggressive advantage of multiple cores, and to be very efficient with 10its use of memory. 11 12Another goal is a "pretty good" backend. The idea here is to do the work 13to get MIR-level inlining enabled, do some basic optimizations in 14Cranelift to capture the low-hanging fruit, and then use that along with 15good low-level optimizations to produce code which has a chance of being 16decently fast, with quite fast compile times. It obviously wouldn't 17compete with LLVM-based release builds in terms of optimization, but for 18some users, completely unoptimized code is too slow to test with, so a 19"pretty good" mode might be good enough. 20 21There's plenty of work to do to achieve these goals, and if we achieve 22them, we'll have enabled a Rust compiler written entirely in Rust, and 23enabled faster Rust compile times for important use cases. 24 25See [issues tagged "rustc"](https://github.com/bytecodealliance/wasmtime/labels/cranelift%3Agoal%3Arustc) 26for a list of some of the things that will be needed. 27 28With all that said, there is a potential goal beyond that, which is to 29build a full optimizing release-capable backend. We can't predict how 30far Cranelift will go yet, but we do have some crazy ideas about what 31such a thing might look like, including: 32 33 - Take advantage of Rust language properties in the optimizer. With 34 LLVM, Rust is able to use annotations to describe some of its 35 aliasing guarantees, however the annotations are awkward and 36 limited. An optimizer that can represent the core aliasing 37 relationships that Rust provides directly has the potential to be 38 very powerful without the need for complex alias analysis logic. 39 Unsafe blocks are an interesting challenge, however in many simple 40 cases, like `Vec`, it may be possible to recover what the optimizer 41 needs to know. 42 - Design for superoptimization. Traditionally, compiler development 43 teams have spent many years of manual effort to identify patterns of 44 code that can be matched and replaced. Superoptimizers have been 45 contributing some to this effort, but in the future, we may be able 46 to reverse roles. Superoptimizers will do the bulk of the work, and 47 humans will contribute specialized optimizations that 48 superoptimizers miss. This has the potential to take a new optimizer 49 from scratch to diminishing-returns territory with much less manual 50 effort. 51 - Build an optimizer IR without the constraints of fast-debug-build 52 compilation. Cranelift's base IR is focused on Codegen, so a 53 full-strength optimizer would either use an IR layer on top of it 54 (possibly using cranelift-entity's flexible `SecondaryMap`s), or 55 possibly an independent IR that could be translated to/from the base 56 IR. Either way, this overall architecture would keep the optimizer 57 out of the way of the non-optimizing build path, which keeps that 58 path fast and simple, and gives the optimizer more flexibility. If we 59 then want to base the IR on a powerful data structure like the 60 Value State Dependence Graph (VSDG), we can do so with fewer 61 compromises. 62 63And, these ideas build on each other. For example, one of the challenges 64for dependence-graph-oriented IRs like the VSDG is getting good enough 65memory dependence information. But if we can get high-quality aliasing 66information directly from the Rust front-end, we should be in great 67shape. As another example, it's often harder for superoptimizers to 68reason about control flow than expression graphs. But, graph-oriented 69IRs like the VSDG represent control flow as control dependencies. It's 70difficult to say how powerful this combination will be until we try it, 71but if nothing else, it should be very convenient to express 72pattern-matching over a single graph that includes both data and control 73dependencies. 74