Efficient Integer Overflow Checking in LLVM (2016) | Hacker News Reader

Efficient Integer Overflow Checking in LLVM (2016)

blog.regehr.org

84 pointsot22 comments

Interesting post, as Regehr's posts tend to be.

Presumably .Net goes to great lengths to optimise overflow-checking, as the checks are enabled for production use. I wonder if they manage to get the overhead to below the 8.7% mentioned in the article.

edit: I had put OpenJDK and .Net but tom_mellior is right to point out that Java has wrapping arithmetic

Why would OpenJDK do integer overflow checking? Java integers have well-defined two's complement wrapping semantics. When you add two positive numbers and get a negative result, this might not be what the programmer wanted, but it is not undefined behavior like it is in C.

Are you maybe mixing this up with array bounds checking?

Oops, you're right! I forgot Java arithmetic wraps, offering (rarely used) methods for overflow-checked arithmetic. [0]

I was right about .Net though. Assuming a checked context, .Net (and C#) throw on overflow, rather than wrapping. [1]

[0] https://docs.oracle.com/en/java/javase/11/docs/api/java.base...

[1] https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

OpenJDK only does overflow checking in a tiny number of cases.

Cunningham's Law strikes again!

You're right of course. Please see my response to tom_mellior.

@dang Can we have a (2016) in the title please.

That's when I added them to perl's add operator. Being about 10% faster than manual checking the high bits. gcc added them about one year later.

Maybe some day llvm will know how to optimize overflow checks as well as JavaScript engines do.

Is this tongue in cheek? JavaScript numbers are floating point, are they not?

No, JS engines optimize heavily for small integers (31 or 32 bits) and dynamically overflow into double range as necessary.

They aren’t literally implemented as floating point in most cases. That’d be crazy! If the number fits in an integer then a sensible implementation uses an integer.

Maybe, but LLVM has the disadvantage that speculating “this won’t overflow” and creating a fast path with that information is not something that can be fixed if more profiling data comes in at runtime saying it was a poor choice.

The C/C++ standards allow compilers to do whatever they want as long as it does not cause observable output changes.

So LLVM could do runtime profiling if it wanted. But I suspect that in the majority of the cases the cost of the profiling would be worse than the potential gains.

Those aren’t the optimizations I’m talking about. That’s not even how JSC optimizes overflow checks.

I’m talking about:

- abstract interpretation using a streamlined version of the octagon domain.

- instruction selection and register allocation hacks to emit the best possible code for checked math. I don’t think llvm has parity with B3 here, particularly in cases where inputs to the math are live on the failing case.

- probably other stuff. IRs that start out with checked math tend to include checked math reasoning in more optimizations.

> - abstract interpretation using a streamlined version of the octagon domain.

Do you have any links/source code where I can read up about this (possibly in the context of compilers)? I've never heard of the term octagon domain before.

If you know about abstract interpretation, here are the relevant papers:

https://www.cs.utexas.edu/~tdillig/cs395/octagon.pdf

https://www-apr.lip6.fr/~mine/publi/article-mine-HOSC06.pdf

If you don't know about abstract interpretation, start at https://en.wikipedia.org/wiki/Data-flow_analysis and https://en.wikipedia.org/wiki/Abstract_interpretation

Having said the above, I can't find any other information on JavaScriptCore using octagons. Searching https://trac.webkit.org/browser/trunk/Source/JavaScriptCore for "octagon" yields nothing.

Post from 2016:

https://news.ycombinator.com/item?id=11462308 (24 comments)

Wow.

I don't want this in release mode.

Please tell me that this overflow checking is turned off by default.

Hm - I was wondering exactly what "ud2" does when it's triggered (looks like an "undefined opcode"... causes a seg fault?), but what's worse? An app that crashes with no apparent cause, or a bank account that resets to $0 if it gets too big?

You’ll get a SIGILL.

You have to explicitly enable UBSan checks:

    -fsanitize=signed-integer-overflow

See the UBSan docs: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

(2016)

Reply on news.ycombinator.com