[rust-dev] Appeal for CORRECT, capable, future-proof math, pre-1.0

Carter Schonwald carter.schonwald at gmail.com
Sun Jan 12 19:53:58 PST 2014

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 <robert at ocallahan.org>wrote:

> On Mon, Jan 13, 2014 at 2:22 PM, Daniel Micay <danielmicay at 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 at mozilla.org
> https://mail.mozilla.org/listinfo/rust-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140112/50617f27/attachment.html>

More information about the Rust-dev mailing list