> 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
