Richard Guenther wrote: > On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini <bonz...@gnu.org> wrote: >>> So while trapping variants can certainly be introduced it looks like >>> this task may be more difficult. >> I don't think you need to introduce trapping tree codes. You can >> introduce them directly in the front-end as >> >> s = x +nv y > > I think this should be > > s = x + y > (((s ^ x) & (s ^ y)) < 0) ? trap () : s > > otherwise the compiler can assume that for the following check > the addition did not overflow.
Ah yeah I've not yet looked at the patches and I did not know which one was which. I actually wrote x + y first and then went back to carefully check them. :-P >> Making sure they are compiled efficiently is another story, but >> especially for the sake of LTO I think this is the way to go. > > I agree. Btw, for the addition case we generate > > leal (%rsi,%rdi), %eax > xorl %eax, %esi > xorl %eax, %edi > testl %edi, %esi > jns .L2 > .value 0x0b0f > .L2: > rep > ret > > which isn't too bad. Well, for x86 it requires the addends to die. This is unfortunately four insns, and combine has a limit of three. but maybe you could make combine recognize the check and turn it to an addv pattern (with the add result unused!); and then CSE or maybe combine as well would, well, eliminate the duplicate ADD... If this does not work, on ARM you can also hope for something like this: ADD R0, R1, R2 XORS R0, R2, R3 XORSMI R1, R2, R3 SWIMI #trap But hey, whatever you get, it's anyway faster than a libcall. :-) Of course there are better choices for x+CONSTANT; using (b == INT_MIN ? trap () : -b) for negation is one example. Paolo