@daniel, the GHC haskell IR predates LLVM, and theres actually some pretty nice examples of LLVM doing AMAZING optimization of bit fiddling haskell code (in fact, for any performance ratio, i can manufacture a natural bit fiddlign example where ghc -fllvm is that much better than ghc -fasm for bit fiddling code currently).
Mind you this only happens in bit fiddling code where LLVM can basically cancel out the composition of long sequences of bit fiddling of the form mortonShuffle . inverseMortonShuffle . mortonShuffle . inverseMortonShuffle, llvm is able to take the GHC IR and algebraically turn it into a No Op function. That said, I definitely think theres ways LLVM can improve support for langs that aren't C, and I've certainly gotten the impression LLVM devs are open to contributions that leave everyone better off. On Sun, Jan 12, 2014 at 8:53 PM, Robert O'Callahan <rob...@ocallahan.org>wrote: > On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay <danielmi...@gmail.com>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 > Rust-dev@mozilla.org > https://mail.mozilla.org/listinfo/rust-dev > >
_______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
