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

Robert O'Callahan robert at ocallahan.org
Sun Jan 12 17:53:41 PST 2014


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/rust-dev/attachments/20140113/cf885f42/attachment-0001.html>


More information about the Rust-dev mailing list