[rust-dev] Integer overflow, round -2147483648

Daniel Micay danielmicay at gmail.com
Mon Jun 23 13:41:29 PDT 2014


On 23/06/14 04:01 PM, John Regehr wrote:
>> I doubt it, since Swift has a high level IR above LLVM IR and the
>> implementation isn't open-source. The language-specific optimizations
>> like removing overflow / bounds checks based on type system rules will
>> almost certainly be done on the high-level SIL IR, not at the LLVM IR
>> layer where most of the information is already lost.
> 
> No, the overflow checks in Swift will turn into LLVM intrinsics such as
> llvm.sadd.with.overflow.  This is also what Rust would use.  Then, the
> IR-level optimizations will try to remove these.  LLVM already has a
> not-great integer range analysis that could be beefed up significantly
> without a whole lot of trouble.

I already exposed these intrinsics as Rust intrinsics and you can make a
user-defined integer type using these for the overloaded operators.

> Of course there's nothing stopping higher-level analyses from also
> attempting to avoid unnecessary overflow checks but I doubt that much or
> any of this is being done.

I don't think they'd have their own high-level IR if they didn't plan on
doing those kinds of optimizations. It's a compile-time hit so it's
there for a reason, and the only reasons I can think of are leveraging
the type system's design to eliminate bounds checks, overflow checks and
to perform devirtualization.

>> Rust 1.0 will be released in about 6 months, and these improvements
>> aren't going to happen in that time. It's a language for the present,
>> not one written for a fantasy architecture / compiler backend in 2025.
> 
> I wasn't arguing that Rust 1.0 should trap on integer overflow, I was
> arguing that the overhead of overflow checking isn't as high as you say.
>  But I'd be happy to look at real data.

I do think Rust should exposed either `checked { }` or operators for
checked arithmetic along with an opt-in lint to deny the unchecked
operators. You can opt-out of a lint for a function/impl/module after
opting into it at a higher scope.

I'm just making it clear that doing this by default would make Rust
slower than Java by default, and I think that would kill off interest in
the language. I know I wouldn't be interested anymore.

This conversation could just as easily be about using compiler
optimizations instead of exposing move semantics and lifetimes in the
type system.

Affine types and region typing is a lot of complexity to tackle an issue
that many people would claim a compiler could do. I don't see a claim
that it can eliminate the overhead of integer overflow checks or bounds
checks to be any less extraordinary, as if it was really as easy as
people are making it out to be then it would already work after all
these years.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140623/6d6e64a4/attachment.sig>


More information about the Rust-dev mailing list