[M3devel] other optimizations to think about?

[Jay K]

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