From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 258CE3858C53; Wed, 14 Jun 2023 08:58:27 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 258CE3858C53
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1686733107;
	bh=u6MSET2x1/y3b7d+kcPrCIrC65jvNBK4qXGDEmn07mo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=SuozC9QkT4EL8TJhJ9+jhvPR/De+V9Wznqj+MMG+SG/21jFKL89FNH4nF2Y4eK/L+
	 ig/So8sscLmAASXIF4zrK4vyqUo3vlm2zkyj7y1+D2FlJ1BfKwsgbmNG6cBkAI//LI
	 UvGCUeJntE9NU8mgUPnH9JuMg/nCnL+sZmU94dtM=
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/90094] better handling of x == LONG_MIN on x86-64
Date: Wed, 14 Jun 2023 08:58:26 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: middle-end
X-Bugzilla-Version: 9.0
X-Bugzilla-Keywords: missed-optimization
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-90094-4-hRD6XicdIj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-90094-4@http.gcc.gnu.org/bugzilla/>
References: <bug-90094-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

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

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 >=3D __LONG_MAX__ - 0x7fffff00 etc.

I mean
void fn (void);

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

void
f2 (long a)
{
  if (a =3D=3D -__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 =3D=3D __LONG_MAX__;
}

void
f6 (long a)
{
  if (a =3D=3D __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 >=3D __LONG_MAX__ - 42;
}

void
f10 (long a)
{
  if (a >=3D __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 <=3D -__LONG_MAX__ + 42;
}

void
f14 (long a)
{
  if (a <=3D -__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.=