On Fri, Mar 6, 2009 at 4:09 PM, Paolo Bonzini <bonz...@gnu.org> wrote: > 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...
Well, I was thinking about detecting the pattern on the tree level instead. s_6 = x.0_2 + y.1_4; D.1597_7 = s_6 ^ x_1(D); D.1598_8 = s_6 ^ y_3(D); D.1599_9 = D.1597_7 & D.1598_8; if (D.1599_9 < 0) goto <bb 3>; else goto <bb 4>; <bb 3>: __builtin_trap (); <bb 4>: This should be recognizable in the ifcombine pass for example, which recognizes CFG patterns. Transforming it to just s_6 = __builtin_addv (x.0_2, y.1_4); <bb 4>: Only ifcombine runs a little too early for that maybe. Richard.