Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I hope optimiztion of integer overflow checking improves in LLVM, since now there is a highly visible project(JavaScriptCore FTL JIT) using the feature. JavaScript semantics pretty much forces you to do integer overflow checking fast.


Not to mention Swift.

FTL has already precipitated other interesting changes in LLVM (to support deoptimisation and GC).


You're referring to the optimisation of storing JS Numbers as integers until they get too large, presumably?


Yes.


Native integer overflow checks can only go so far, there, since there's no 52-bit integer type.


What? JavaScript engines check for 32-bit integer overflow and promote to double.


IIRC v8 promotes to double at 31 bits. But yeah.


On 64bit architectures V8 promotes at 32bits.

(and if we talk about optimizing compilation things are getting more complicated as there int31, int32 and float64 can all coexist and you can have 31-bit integer stored in a float64 value - if operation was specialized for floating point values)


Yeah, V8 is a bit of an odd one out here. Everyone else just promotes once a signed 32-bit int overflows.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: