Crystal: Add suport for Int overflow checking

[endSly]

LLVM provides some builtin functions for checking overflow in arithmetic operations (http://llvm.org/docs/LangRef.html#arithmetic-with-overflow-intrinsics) with a miniumum overhead.
A PR would be accepted with support for overflow checking?

[asterite]

This is something that we will definitely consider before 1.0.

The real question is how to deal with this. There was a recent discussion about this on Google Groups

[ysbaddaden]

I like the checked and unchecked blocks in C# that make the choices explicit.

I'm not sure about the new operators in Swift, it requires to learn a special syntax, but it makes the overflow choices explicit too.

I'm not sure about changing the default behavior between release (never check) and non release (never check) modes of Rust, unless the behavior specified.

AFAIK Go always overflows and never checks, right?

[RX14]

I think I like rust's way of working myself. It just seems like the simplest solution.

[endSly]

I've been doing some research on performance impact using llvm primitives for overflow checked operations (llvm.*.with.overflow). Those are the results (Code here):

Fibonacci unsafe 110.91  (± 5.88%)  1.02× slower
  Fibonacci safe 113.45  (± 5.65%)       fastest

[waj]

@endSly good job! But the result gives the checked operation is faster? I'd like to see more benchmarks of more complex examples with many calculations in a no so tight loop. Anyway I guess that branch prediction in modern cpus can make the difference quite acceptable for most use cases.

[endSly]

I've added tests for safe and unsafe 6x6 matrix exponentiation (here) and these are the results:

Matrix exp unsafe  32.66k (± 1.51%)       fastest
  Matrix exp safe  31.06k (± 1.01%)  1.05× slower

[ozra]

Both the release vs dev solution (off/on) and explicit checked / unchecked blocks sounds good to me. If the explicit route is chosen, I think it should also apply to more than just overflow checks, for instance bounds checking. And also then, checks should _still_ be done in dev compiles and stop the program / planned crash.

[RX14]

:-1: for bounds checks ever being off outside Pointer(T). Pointers going out of bounds is a potential remote code execution. Overflows are typically not as severe.

I've actually rethought my position on this overall. I think it should be explicit unchecked blocks with the default being checked. Subject to the performance hit not being unreasonable for a moderately mathematical piece of code. Given how small the performance impact should be for most code, I think this should be left on by default (even in --release) for safety. For the small bits of bit fiddling which require overflow to happen, or for super performance critical math-heavy sections which require unchecked maths, the unchecked block exists.

[drosehn]

Years ago I worked with a systems-programming language which had overflow checking. For the types of programs which we wrote, the cost of checking was so low that it was almost always worth it to leave the checking on. Catching some rare bug where it happened was almost always worth the tiny cost, even if the checking caught only one bug per year.

[drosehn]

Hmm, I lost a sentence somewhere along the line: There were a very small number of times where we found the overhead unacceptable, so I certainly do want to have some way to turn off the extra checks.