“Performance gains due to improvements in compiler optimizations will double
the speed of a program every 18 years” © Proebsting’s Law

When we solve equations, we try to simplify them first, e.g. `Y = -(5 - X)` can be simplified to just `Y = X - 5`. In modern compilers it’s called “Peephole Optimizations”. Roughly speaking, compilers search for certain patterns and replace them with corresponding simplified expressions. In this blog post I’ll list some of them which I found in LLVM, GCC and .NET Core (CoreCLR) sources.

Let’s start with simple cases:

and check the 4th one in C++ and C# compilers:

Now let’s take a look at what the compilers output:

All three C++ compilers have just one `imul` instruction. C# (.NET Core) has two because it has a very limited set of available peephole optimizations and I’ll list some of them later. Be sure to note, the entire InstCombine transformation implementation, where peephole optimizations live, in LLVM takes more than 30K lines of code (+20k LOC in DAGCombiner.cpp). By the way, here is the piece of code in LLVM responsible for the pattern we are inspecting now. GCC has a special DSL which describes all peephole optimizations, and here is the piece of that DSL for our case.

I decided, just for this blog post, to try to implement this optimization for C# in JIT (hold my beer 😛):

Let’s now test my JIT improvement (see EgorBo/coreclr commit for more details) in VS2019 with Disasmo:

Let’s go back to C++ and trace the optimization in Clang. We need to ask clang to emit LLVM IR for our C++ code via `-emit-llvm -g0` flags (see godbolt.org) and then give it to the LLVM optimizer opt via `-O2 -print-before-all -print-after-all` flags in order to find out what transformation actually removes that extra multiplication from the `-O2` set. (see godbolt.org):

So it’s InstCombine indeed, we can even use it as the only optimization for our code for tests via `-instcombine` flag passed to `opt`:

Let’s go back to the examples. Look what a cute optimization I found in GCC sources:

And that’s true, e.g.: `4 == 8 - 4`. Any odd number for C (C usually means a constant/literal) will always be false for the expression:

### Optimizations vs IEEE754

Lots of this type of optimizations work for different data types, e.g. `byte`, `int`, `unsigned`, `float`. The latter is a bit tricky e.g. you can’t simplify `A - B - A` to `-B` for floats/doubles, even `(A * B) * C` is not equal to `A * (B * C)` due to the IEEE754 specification. However, C++ compilers have a special flag to let the optimizers be less strict around IEEE754, NaN and other FP corner cases and just apply all of the optimizations - it’s usually called “Fast Math” (`-ffast-math` for clang and gcc, `/fp:fast` for MSVC). Btw, here you can find my feature request for .NET Core to introduce the “Fast Math” mode there: dotnet/coreclr#24784).

As you can see, two `vsubss` were eliminated in the `-ffast-math` mode:

The C++ optimizers also support `math.h` functions, e.g.:

The square root is always positive:

Why should we calculate sqrt(X) if we can just calculate C^2 in compile time instead?:

More sqrt optimizations:

or `exp`:

And my favorite one:

There are lots of boring bit/bool patterns:

### Machine-dependent optimizations

Some operations may be faster or slower on different CPUs, e.g.:

`mulss`/`mulsd` usually have better both latency and throughput than `divss`/`divsd` for example, here is the spec for my Intel Haswell CPU:

We can replace `/ C` with `* 1/C` even in the non-“Fast Math” mode if `C` is a power of two. Btw, here is my PR for .NET Core for this optimization: dotnet/coreclr#24584.

The same rationale for:

`test` is better than `cmp` (see my PR dotnet/coreclr#25458 for more details):

And what do you think about these ones?:

How many `mul` are needed to perform `pow(X, 4)` or `X * X * X * X`?

Just 2! Just like for `pow(X, 3)` and unlike `pow(X, 3)` we don’t even use the `xmm1` register.

Modern CPUs support a special FMA instruction to perform `mul` and `add` in just one step without an intermediate rounding operation for `mul`:

Sometimes compilers are able to replace entire algorithms with just one CPU instruction, e.g.:

### Traps for optimizations

We can’t just find patterns & optimize them:

• There is a risk to break some code: there are always corner-cases, hidden side-effects. LLVM’s bugzilla contains lots of InstCombine bugs.
• An expression or its parts we want to simplify might be used somewhere else.

I borrowed a nice example for the second issue from “Future Directions for Optimizing Compilers” article.
Imagine we have a function:

We need to perform 3 operations here: `0 - a`, `0 - b`, и `na + nb`. LLVM simplifies it to just two operations: `return -(a + b)` - what a smart move, here is the IR:

Now imagine that we need to store values of `na` and `nb` in some global variables, e.g. `x` and `y`:

The optimizer still recognizes the pattern and simplifies it by removing redundant (from its point of view) `0 - a` and `0 - b` operations. But we do need them! We save them to the global variables! Thus, it leads to this:

4 math operations instead of 3! The optimizer has just made our code a bit slower. Now let’s see what C# RuyJIT generates for this case:

RuyJIT doesn’t have this optimization so the code contains only 3 operations :-) C# is faster than C++! :p

### Do we really need these optimizations?

Well, you never know what the final code will look like after inlining, constant folding, copy propagation, CSE, etc.
Also, both LLVM IR and .NET IL are not tied to a specific programming language and can’t rely on quality of the IR it generates. And you can just run your app/lib with `InstCombine` pass on and off to measure the performance impact.

### What about C#?

As I said earlier, peephole optimizations are very limited in C# at the moment. However, when I say “C#” I mean the most popular C# runtime - CoreCLR with RuyJIT. But there are more, including those, using LLVM as a backend: Mono (see my tweet), Unity Burst and LILLC - these runtimes basically use exactly the same optimizations as clang does. Unity guys are even considering replacing C++ with C# in their internal parts. By the way, since .NET 5 will include Mono as an optional built-in runtime - you will be able to use LLVM power for such cases.

Back to CoreCLR - here are the peephole optimizations I managed to find in the `morph.cpp` comments (I am sure there are more):

There are also some in `lowering.cpp` (machine-dependent ones) but in general RyuJIT obviously loses to С++ compilers here. RyuJIT just focuses more on different things and has a lot of requirements. The main one is - it should compile fast! it’s called JIT after all. And it does it very well (unlike the C++ compilers - see “Modern” C++ Lamentations). It’s also more important to de-virtualize calls, optimize out boxings, heap allocations (e.g. Object Stack Allocation). However, since RyuJIT is now supporting tiers, who knows maybe there will be a place for peephole optimizations in future in the tier1 or even a separate tier2 ;-). Maybe with some sort of DSL to declare them, just read this article where Prathamesh Kulkarni managed to declare an optimization for GCC in just a few lines of DSL:

for the following pattern:

Any volunteers to try, just for fun, to make that DSL to produce RuyJIT code? 😆