gistfile1.txt

Cretonne IL is tuned for codegen. You can see this in the use of EBBs, br_table
not taking arguments, the lack of builtin def-use lists, the lack of a
general-purpose switch statement, the precense of instructions specialized to
take an immediate argument, and other places.

I'm entertaining the idea that this works out well for Rustc. It'll make
"fast compile" use cases, both "debug" and "pretty good optimization" builds
faster. Compared to LLVM's 4 layers in a typical compile (LLVM IR, SelectionDAG,
MachineFunction, MC), Cretonne uses one IL throughout, and it's designed
to be very compact.

"Pretty good optimization" is important because in many cases, -O0 Rust code
is too slow to debug with, so it'll be great to be able to do this with fast
compile times. However, the other side of the tradeoff is that if we
eventually implement higher-powered middle-end optimization, it'll look more
like a separate infrastructure layer than just passes that operate on the
base IL like in LLVM, so there will be some extra overhead. But if we assume
that for most developers, final release builds aren't the build times that
matter most, this tradeoff may be favorable.

One concern with this tradeoff is that if more developers use
"pretty good optimization" builds rather than full-optimized release builds,
bugs involving UB getting exposed by optimization may go undetected longer.
But perhaps in Rust this should be less of a concern than in C++.

This approach also means that we wouldn't be as tied to specific optimizer
designs, such as VSDG, or other designs, because it'd be more of an independent
layer on top.