This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: New no-undefined-overflow branch
Richard Guenther wrote:
> On Fri, Mar 6, 2009 at 3:29 PM, Paolo Bonzini <bonzini@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