[M3devel] other optimizations to think about?

[Jay K]

proofreading...

> strict_overflow is something like where the compiler assumes there
shall be no signed integer overflow, ?or that signed integer overflow
doesn't trap?, and then make optimizations based on that assumption.
> I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow.

DOES trap
systematic ASSUMPTION

 - Jay


----------------------------------------
> From: jay.krell at cornell.edu
> To: m3devel at elegosoft.com
> Subject: other optimizations to think about?
> Date: Sun, 4 Jul 2010 14:44:26 +0000
>
>
> Given that we know vaguely what these things are:
>     flag_strict_aliasing = 0;
>     flag_strict_overflow = 0;
>
>
> I'm inclined to turn them off in m3cg/parse.c like how a few others are.
> They sound kind of scary and not valuable.
>
>
> strict_aliasing I believe is something like where if you have pointers to integers and pointers to floats, writes through one are assumed to not affect reads through the other.
>   So the reads can be cached in registers across the writes.
> Tony has mentioned a need for alias analysis a few times, so..
> Or we could just turn it off in unsafe modules or once we see a loophole, perhaps.
>
>
> strict_overflow is something like where the compiler assumes there shall be no signed integer overflow, ?or that signed integer overflow doesn't trap?, and then make optimizations based on that assumption.
> I don't feel I'm yet willing to give up a possibly systematic that signed oveflow silently overflow.
> This optimization in fact I believe/thought defeats the obvious ways to check for overflow.
> int add(int a, int b)
> { int c = a + b;
>    if (c < a)
>       error_and_exit("overflow");
>   return c;
> }
>
> strict overflow means c can't be less than a, so the check can be optimized away.
>
> I wasn't able to reproduce this, granted, with:
>  Apple gcc 4.2
>   Debian 5.0 gcc 4.3
>   self-built gcc 4.5
>
> http://gcc.gnu.org/gcc-4.2/changes.html
>
> does sound like what I'm saying though.
>
> er, wait, what I showed is the unsigned algorithm, duh.
>
> void overflow(void);
>
> int add(int a, int b)
> {
>   int c = (a + b);
>   int asign = (a < 0);
>   if (asign == (b < 0) && asign != (c < 0))
>     overflow();
>   return c;
> }
>
> still, doesn't have a problem.
>
> (explanation:
> overflow occured if inputs have same sign and output differs from their sign
> overflow cannot occur if inputs have different sign
> sign(x) equivalent to (x < 0) (maps one to one: negative => 1, positive => 0)
> )
>
>
>  - Jay
>