Re: Ada front-end depends on signed overflow

[Eric Botcazou <ebotcazou at adacore dot com>]

> Once again, have you actually examined how awtul the code we
> generate now is?

Yes, I have.  Indeed not pretty, but suppose that we managed to cut the 
overhead in half, would that make -gnato really more attractive?

> Well of course that's just a plain bug, should be addressed as such.
> Obviously no one is using -ftrapv, so it will expose lots of bugs
> I would guess.

Yes, that's my impression too.

> Clearly the status quo is entirely unacceptable, so what's your
> recommendation of how we generate at least vaguely respectable
> code for overflow checking

Tough question, but I'm almost certain of something: since we need to recover 
from overflow checks, we have to expose them to the EH machinery, which 
nowadays means in the GENERIC tree IL.

From that, we have 2 alternatives: synchronous or asynchronous exceptions.
The current implementation is synchronous, as we explicitly raise exceptions 
in the code by calling a routine.  I guess you're pushing for asynchronous 
exceptions since this is probably the only efficient approach, i.e. we rely 
on the hardware to trap and try to recover from that.

If so, currently tree_could_trap_p will return true for all arithmetic 
operations whose type is TYPE_TRAP_SIGNED, with

#define TYPE_TRAP_SIGNED(NODE) \
  (flag_trapv && ! TYPE_UNSIGNED (NODE))

That seems far too broad.  We could instead flag expressions on a case-by-case 
basis, but I guess that would put too much burden on the tree optimizers.  So 
a compromise could be to use a specific bit for TYPE_TRAP_SIGNED and instruct 
Gigi to use the TYPE_TRAP_SIGNED-variant of a given type, when overflow 
checks are requested for an operation.

Then we would need to implement the overflow-aware instruction patterns for 
every architecture.  AFAICS only Alpha has (some of) them.  And fix the RTL 
optimizers in the process.

-- 
Eric Botcazou