gratilup

Don't even need Incredibuild, even MSBuild or just plain /MP option in VC++ can take advantage of it. A build from VS of the Unreal Engine 4 client takes around 2 min, for example.

They are full 256 bit wide now, that's how it can claim a 2x float perf. improvement. It also doesn't have an "AVX" offset.

Now imagine a Threadripper with the Zen2 cores, higher IPC and frequency would be certainly welcome. Have the 32 core 2990WX and it's an incredible CPU for compiling large C++ programs, running big test suites and never having to worry about running too many tasks at the same time.

As a compiler engineer, those are some of the least impressive things done by modern compilers. Why? Because there isn't anything smart behind them, it's pure pattern matching.

You basically just said that the Windows kernel code is beautiful, because they are using exactly the same coding style...

I'm the main developer of the new optimizer. It's a bit too much to say it replaces the old one, it's more of an addition. I was aware of this issue with initializing local arrays, it was on the TODO list - hopefully for the next VS.

The EH info looks the same when in SSA form - when building SSA the right PHIs are inserted for the values potentially defined in EH blocks.

Visual C++ does not use the GCC naming for flags. The flag will likely be renamed to something shorter in the final release in Update 3.

That's why that patterns is not applied in the new optimizer, unless the Bit Estimator proves x+1 does not overflow. After it was implemented to behave like what other compilers do, I analyzed several applications and libraries and it would have introduced silent security problems - I explained in the blog post.

What I meant to say is that if you have an overflow in those cases, the results of the expression is definitely not what you wanted - this is going to propagate and "damage" other expressions. Applying the optimization in that case might produce a different result. An example is this new transformation from the blog post: (a * C1) / C2 -> a * (C1/C2), where a * C1 might overflow. For 8 bit numbers with a = 106 and C1 = C2 = 17 we get

initial: (106 * 17) / 17 = 10 (overflow) / 17 = 0

optimized: 106 * (17 / 17) = 106 * 1 = 106

So in this case the optimized version gives the expected result - it's still different than the initial expression, so it falls under the "undefined overflow" optimizations category.

The optimizer will be ported to .NET Native soon, it should help code quality quite a lot. The JIT is a completely different matter though: it's a different project, done by a different team - copy-paste of the source code is definitely not going to work. JIT compilers also have different priorities, unlikely they would port all parts of a large optimizer.

There are only a few places where the undefined behavior is exploited right now. For those cases, if there is overflow in the original expression the program is pretty much screwed anyway; they are also done by LLVM/GCC. The case that mostly concerns people when they hear about undefined behavior (a+C > a -> true) was avoided, it would silently break too many applications.

I tried to have a simple example, maybe it was too simple. You are right, an OR with a constant is enough to know it is not zero. For this case the Bit Estimator also knows b = [3, 4083], writing something that takes advantage of this info would have been more interesting.

Hi, I'm the author of the blog post and optimizer. We had SSA since around 1999-2000, just that some important components like the expression optimizer were written before that and not updated with support for SSA. The difference is a lot more than just SSA, the blog has just a few examples. The new framework started as being somewhat similar to InstCombine, since then it got much larger and it will be the place where more optimizations will be integrated, hopefully replacing some older ones. To answer your question: SSA is built with both types of exceptions and the new optimizer works as expected, except a few cases where it would be unsafe. It seems that the rejection rules are a bit too aggressive in your example, it's obviously safe to optimize in this case - thanks for the example!