bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: testing for signed char / short / int addition overflow


From: Paul Eggert
Subject: Re: testing for signed char / short / int addition overflow
Date: Sun, 14 Mar 2021 21:47:44 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1

On 3/14/21 7:59 PM, Bruno Haible wrote:
The functions my_signed1_overflow, my_signed2_overflow
in the attached file produce better machine code than the corresponding
functions signed1_overflow, signed2_overflow that use intprops.h primitives.

That wasn't true on my platform (Ubuntu 20.10 x86-64, GCC 10.2.0-13ubuntu1 with -O2). But I expect that doesn't matter much since the signed1_overflow and signed2_overflow functions were probably not what you wanted. For example, signed1_overflow simply did this:

        endbr64
        xorl    %eax, %eax
        ret

That is, it always returned 'false', which is a correct implementation of the macro since adding two signed char values cannot overflow on my platform.

I expect you meant something more like the attached foo1.c. On my platform, its signed1_overflow seems more efficient than my_signed1_overflow as it is 6 rather than 9 insns (no branches in either case). In contrast, signed2_overflow (typically 8 insns with one typically-not-taken conditional branch) seems in the same ballparck as as my_signed2_overflow (9 insns, no branches). And signed4_overflow (4 insns, no branches) is definitely faster than my_signed4_overflow (9 insns, no branches).

If I switch to clang 11.0.0-2 on the same platform (which omits a check that GCC includes), the numbers are:

signed1_overflow: 3 insns
my_signed1_overflow: 6 insns
signed2_overflow: 3 insns
my_signed2_overflow: 6 insns
signed4_overflow: 3 insns
my_signed4_overflow: 8 insns

so here, intprops.h seems the clear winner overall.

I'd say that for these platforms, intprops.h is OK as-is. Perhaps on other compilers it could be improved significantly, but I'm not sure how much we should worry about optimizing for compilers other than GCC.

I installed the attached commentary patch to intprops.h to try to clear up some of the confusion you mentioned in this and your other email. If the GCC-vs-clang inefficiency is of concern perhaps someone could file a GCC bug report.

Attachment: 0001-intprops-improve-commentary.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]