Re: FWD: FLOATING-POINT CONSISTENCY, -FFLOAT-STORE, AND X86

[Jeffrey A Law <law at hurl dot cygnus dot com>]

  In message <9812152009.AA19622@nile.gnat.com>you write:
  > I'd like to comment on this issue for Ada, and I'll explain what the
  > current situation is in GNAT and how (small?) compiler changes could
  > improve efficiency of overflow checking.
Thanks.  I'd peeked at the Ada compiler to try and figure out how it handled
the overflow issues and got totally lost.

  > The compiler does all arithmetic that needs to be checked for overflows
  > using a wider type. Regular 32-bit integers are calculated using 64-bits.
Ouch!  Yea, that's got to be quite inefficient.

  > To get efficient
  > overflow checks, the compiler should be able to take advantage of overflow
  > bits in the status register and raise an exception when an overflow is
  > detected.
Right.

  > This would be a place where the backend could help, although I don't
  > know exactly how this should be implemented.
Shoundn't be all that hard.  Most of the work is in the front/middle end.

Somehow the front end has to specify to the middle end where overflow checks
need to occur.  Presumably you'd need a new tree code for that.

The middle end would convert that tree code into a trap_if or similar rtl
construct which checked the overflow bit.

  > Reordering integer additions is fine for Ada-95, as exceptions do not need 
  > to be exact as long as they occur in the same block. It is also allowed to
  > not raise an exception at all if the final result is mathematically correct
  > even if intermediate values would have overflowed. Also when some operation
  > would have no external effect in the absense of checks, the compiler is
  > allowed to remove the checks and as a result usually is able to remove the
  > operation as well.
Ah.  Excellent.  That's a pretty reasonable definition.  It explains why
fold-const is allowed to perform reassociations which may mask overflows or
make them inexact.

Thanks!

jeff