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 CDCA13858C2F; Tue, 13 Feb 2024 09:21:39 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CDCA13858C2F
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1707816099;
	bh=fzzUEgkTVEKeXmciyJHo6BbZzGQCiN6w1qxeW4Wp8ww=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=pA87pO6E7ZZtyA25x84tYM8JxzMK+y3IJQIF9H05pQaK2G4a1Bp+DK5tOwPy4zZIs
	 +LRM1dnA/P6eR5JOlLKZ5PcS/kZPH+J9KjKQSx6xPHrbxu7HxT4cPdMRkradP6sLGl
	 Q6XgFMlD2FY4ZLS5gbqrQmCgkbTVgZGuwjtpmkIs=
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at
 -O with ipa-modref on aarch64
Date: Tue, 13 Feb 2024 09:21:38 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 14.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 12.4
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-113787-4-XiDXU6GLA5@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-113787-4@http.gcc.gnu.org/bugzilla/>
References: <bug-113787-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=3D113787

--- Comment #14 from rguenther at suse dot de <rguenther at suse dot de> ---
On Tue, 13 Feb 2024, hubicka at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113787
>=20
> --- Comment #13 from Jan Hubicka <hubicka at gcc dot gnu.org> ---
> So my understanding is that ivopts does something like
>=20
>  offset =3D &base2 - &base1
>=20
> and then translate
>  val =3D base2[i]
> to
>  val =3D *((base1+i)+offset)
>=20
> Where (base1+i) is then an iv variable.
>=20
> I wonder if we consider doing memory reference with base changed via offs=
et a
> valid transformation. Is there way to tell when this happens?

IVOPTs does the above but it does it (or should) as

  offset =3D (uintptr)&base2 - (uintptr)&base1;
  val =3D *((T *)((uintptr)base1 + i + offset))

which is OK for points-to as no POINTER_PLUS_EXPR is involved so the
resulting pointer points to both base1 and base2 (which isn't optimal
but correct).

If we somehow get back a POINTER_PLUS that's where things go wrong.

Doing the above in C code would be valid input so we have to treat
it correctly (OK, the standard only allows back-and-forth
pointer-to-integer casts w/o any adjustment, but of course we relax
this).

IVOPTs then in putting all of the stuff into 'offset' gets at
trying a TARGET_MEM_REF based on a NULL base but that's invalid.
We then resort to a LEA (ADDR_EXPR of TARGET_MEM_REF) to compute
the address which gets us into some phishy argument that it's
not valid to decompose ADDR_EXPR of TARGET_MEM_REF to
POINTER_PLUS of the TARGET_MEM_REF base and the offset.  But
that's how it is (points-to treats (address of) TARGET_MEM_REF
as pointing to anything ...).

> A quick fix would be to run IPA modref before ivopts, but I do not see ho=
w such
> transformation can work with rest of alias analysis (PTA etc)

It does.  Somewhere IPA modref interprets things wrongly, I didn't figure
out here though.=