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 2E86D3858C5E; Mon,  3 Apr 2023 17:57:47 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E86D3858C5E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1680544667;
	bh=AcB6d7Gzr4fJH8XxnfbM9D4b9VJR8wyHnljjyZLckXo=;
	h=From:To:Subject:Date:From;
	b=BGL40K4a5p0F3gtyonq026ZVU9A3kQr7cnrJGcjBlbdd24CTAOZCj57k4Qn7OvDbv
	 qzjVgPGp0YW32NTlhb5NLfRm7i5Zl/ZtdDINYe190Ag9MISVWO1GdXWDf1sT4sow8T
	 7fnezwmTN86B3Ql58BT7T6uF3APsSMEymbKgyT9o=
From: "manolis.tsamis at vrull dot eu" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/109393] New: Very trivial address calculation
 does not fold
Date: Mon, 03 Apr 2023 17:57:46 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: 
X-Bugzilla-Severity: normal
X-Bugzilla-Who: manolis.tsamis at vrull dot eu
X-Bugzilla-Status: UNCONFIRMED
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: bug_id short_desc product version bug_status
 bug_severity priority component assigned_to reporter target_milestone
Message-ID: <bug-109393-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=3D109393

            Bug ID: 109393
           Summary: Very trivial address calculation does not fold
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: manolis.tsamis at vrull dot eu
  Target Milestone: ---

The following function

int func(int *a, int j) {
  int k =3D j - 1;
  return a[j - 1] =3D=3D a[k];
}

surprisingly does not fold to `return 1;` at -O2 or higher (with any GCC
version). It can also be seen here: https://godbolt.org/z/cqr43q7fq

There are a lot of variants for this behaviour but this is the most apparen=
t.
As can be seen in the godbolt link, the issue seems to be a combination of:

  1) The -1 in a[j - 1] is turned into GIMPLE equivalent with *((a + (ulong=
) j)
+ (ulong) -1) but a[k] is turned into *(a + (ulong) (j - 1)).
  2) The -1 is never propagated outside of the (long unsigned int) casts ev=
en
if it's completely legal/possible.

I feel that I'm missing something here about pointer rules / historical con=
text
of these choices and I would appreciate if someone more knowlegable could
explain this combination to me.

There are a lot of cases where this can lead to inefficient codegen but most
prominently this is the reason for a additional redundant load in a hot loo=
p of
SPEC2017's nab in the function downheap_pairs and similar missed optimizati=
ons
in omnetpp's shiftup function.

Hence this issue can both cause very unexpected missed optimization (as in =
the
example) and also decreases the performance of important benchmarks.

Note: The testcase is not optimized even with -fno-wrapv or -fstrict-overfl=
ow,
but does optimize with -fwrapv which is the reverse of what I would expect
since -fno-wrapv should be more permissive?=