Shared publicly  - 
Nice blog post from Dan Luu about the overhead of integer overflow checking:

One thing to keep in mind is that the overflow checking that we did for Clang is really not tuned for performance. Our implementation replaces each operation with a checked version: the LLVM x.with.overflow intrinsics. No problem so far! But then, every check is immediately followed by a branch to error handler. This is nice because it gives very precise information about what overflowed, but it is not the performant implementation. To do this right, you want to OR together a whole expressions' worth (or more) of overflow flags and then put a branch at the end. But now you have to go back and figure out what happened if you want to print a good diagnostic. Since our primary focus was diagnostics and not performance, we didn't do that stuff. So Clang integer overflow checking is not that fast.

Of course there are other problems too, such as the poor register allocation decision in Dan's post. Another major problem is that LLVM lacks a solid value range analysis that could be used to remove provably unnecessary overflow checks. So basically there's a lot of room for improvement.

Anyhow Dan's blog doesn't allow comments so I wanted to leave this somewhere.

Also I am psyched that Souper (our LLVM superoptimizer) will soon understand the x.with.overflow intrinsics and sooner or later we can expect it to do a somewhat decent job of getting rid of unnecessary checks.
How much overhead should we expect from enabling integer overflow checks? Using a compiler flag or built-in intrinsics, we should be able to do the …
John Regehr's profile photoRichard Smith's profile photoDan Luu's profile photo
Dan Luu
I hope my post didn't come across as too critical. I'm really glad clang has support for this. The unsigned integer overflow check finds bugs in half the software I try it on. Also, glad to hear that Souper will help speed this up!
Hi Dan, your post is great, it's important (and fun) to look at this stuff.

Regarding unsigned overflows, we always had a hard time with those, since many of them aren't bugs at all, but of course some of them are. If you have time to write up a post about your unsigned findings that would be really nice to see.
+Dan Luu Try using -fsanitize-undefined-trap-on-error. That flag turns off the precise diagnostic information that +John Regehr mentioned, and also turns off UBSan's ability to keep running code (with the 2's complement result) after hitting an overflow (which also penalizes performance). For your "add two ints" function, clang generates this code with that flag:

        addl    %esi, %edi
        jo      .LBB0_1
        movl    %edi, %eax
Add a comment...