Currently we use the same set of optimisation passes that clang does. This is fine for the most part, since our semantics and codegen are similar enough for the set of passes to be reasonably good.
However, Rust isn’t C/C++, and some things don’t match up perfectly. Looking at LLVM’s Frontend Performance Guide, a few of those points seem to apply to Rust. Two notable points are:
If you language uses range checks, consider using the IRCE pass. It is not currently part of the standard pass order and For languages with numerous rarely executed guard conditions (e.g. null checks, type checks, range checks) consider adding an extra execution or two of LoopUnswith and LICM to your pass order. The standard pass order, which is tuned for C and C++ applications, may not be sufficient to remove all dischargeable checks from loops
For looking at the IRCE pass it is targeted at eliminating checks about the range of a value. This would include bounds checks for indexing. Similarly, the second point also applies to bounds checks, but may also help eliminate unecessary null checks and similar.
I think that continuing to use the basic C/C+±tuned pipeline is only going to hinder the effectiveness of the optimizer. I propose then that we use our own pipeline that can be tuned to be better for Rust code, though still based on the Clang base pipeline.