On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay <[email protected]> wrote:
> -fsanitize=signed-integer-overflow: Signed integer overflow, including > all the checks added by -ftrapv, and checking for overflow in signed > division (INT_MIN / -1). > > Why not measure the impact of this on Firefox performance? We'll have > a concrete answer about half of the picture (but not about the cost > for unsigned or checks on overlong shifts and for division by zero). > That would give us neither an upper bound on overhead (due to excluding unsigned), nor a lower bound (due to no range analysis or LLVM changes). But it might be interesting... Inter-procedural optimization in LLVM can only eliminate dead code, > propagate constants, inline/merge functions and bubble up effects. > > As far as I know, doing more takes way too long. Eliminating array > bounds checks and reasoning about arithmetic just doesn't really > happen. > So not even as good as Java and JS JITs? Sad. > The best hope for an inner loop is for loop-vectorize/slp-vectorize to > do their work, and they won't if there are overflow/carry checks. > > LLVM is designed to optimize C code, and deviating from that kind of > code generation without losing a lot of performance means doing your > own optimizations on your own intermediate format like Haskell. > I would rather not treat LLVM as immutable. Rob -- Jtehsauts tshaei dS,o n" Wohfy Mdaon yhoaus eanuttehrotraiitny eovni le atrhtohu gthot sf oirng iyvoeu rs ihnesa.r"t sS?o Whhei csha iids teoa stiheer :p atroa lsyazye,d 'mYaonu,r "sGients uapr,e tfaokreg iyvoeunr, 'm aotr atnod sgaoy ,h o'mGee.t" uTph eann dt hwea lmka'n? gBoutt uIp waanndt wyeonut thoo mken.o w
_______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
