[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
          Component|rtl-optimization            |middle-end

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note I noticed clang turns __builtin_sub_overflow case into the code for the ==
LONG_MIN case.

[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

[eggert at cs dot ucla.edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094

Paul Eggert <eggert at cs dot ucla.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |eggert at cs dot ucla.edu

--- Comment #3 from Paul Eggert <eggert at cs dot ucla.edu> ---
Slightly better is this equivalent:

unsigned f (long a)
{
  return __builtin_sub_overflow (0, a, &a);
}

which gcc -O2 (or -Os) compiles into:

f:      xor     %eax, %eax
        neg     %rdi
        seto    %al
        ret

which with GCC is one byte less machine code than the __builtin_sub_overflow(a,
1, &a) approach.

[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org,
                   |                            |uros at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
But then shouldn't we do it not just for equality/non-equality comparisons
against 0x8000000000000000, but also for equality/non-equality comparisons
against 0x7fffffffffffffff or signed non-equality comparisons like >
__LONG_MAX__ - 42
or >= __LONG_MAX__ - 0x7fffff00 etc.

I mean
void fn (void);

unsigned
f1 (long a)
{
  return a == -__LONG_MAX__ - 1;
}

void
f2 (long a)
{
  if (a == -__LONG_MAX__ - 1)
    fn ();
}

unsigned
f3 (long a)
{
  return __builtin_sub_overflow_p (0, a, 0L);
}

void
f4 (long a)
{
  if (__builtin_sub_overflow_p (0, a, 0L))
    fn ();
}

unsigned
f5 (long a)
{
  return a == __LONG_MAX__;
}

void
f6 (long a)
{
  if (a == __LONG_MAX__)
    fn ();
}

unsigned
f7 (long a)
{
  return __builtin_add_overflow_p (a, 1, 0L);
}

void
f8 (long a)
{
  if (__builtin_add_overflow_p (a, 1, 0L))
    fn ();
}

unsigned
f9 (long a)
{
  return a >= __LONG_MAX__ - 42;
}

void
f10 (long a)
{
  if (a >= __LONG_MAX__ - 42)
    fn ();
}

unsigned
f11 (long a)
{
  return __builtin_add_overflow_p (a, 43, 0L);
}

void
f12 (long a)
{
  if (__builtin_add_overflow_p (a, 43, 0L))
    fn ();
}

unsigned
f13 (long a)
{
  return a <= -__LONG_MAX__ + 42;
}

void
f14 (long a)
{
  if (a <= -__LONG_MAX__ + 42)
    fn ();
}

unsigned
f15 (long a)
{
  return __builtin_sub_overflow_p (a, 43, 0L);
}

void
f16 (long a)
{
  if (__builtin_sub_overflow_p (a, 43, 0L))
    fn ();
}

The question if it should be done in the cstoredi4 and cbranchdi4 expanders, or
matched later say during combine, or peephole2.

[Bug middle-end/90094] better handling of x == LONG_MIN on x86-64

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90094

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
One argument against doing it during expansion is that if we need the large
constant for other purposes, loading it with movabsq and just doing comparison
is better, the overflow way also clobbers the register which is being compared.