From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id E5FA4385803F; Tue, 13 Feb 2024 18:21:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E5FA4385803F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1707848508; bh=31BJ6B+mEDtJL55MVL1ThfOeQwB2bdrMhdFxIbl/1NY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=OzbboYQb4SDSahxAwgP2+a4zwlxqVbPPlnT7WUyUsQVAcN+rL/X8RtNyXDtORM0c+ RjB9fs4MQ33GYoJDlqXPA0yEBe+gsF2wphCRVnBll0wUXVMI9C5g6Dw5+7RrWTw9rE qVRbDBDkRZNpH4uL4OXnrfNyFTLdS8w5oFUAvxuk= From: "hubicka at ucw dot cz" 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 18:21:47 +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: hubicka at ucw dot cz 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: In-Reply-To: References: 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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D113787 --- Comment #15 from Jan Hubicka --- >=20 > IVOPTs does the above but it does it (or should) as >=20 > offset =3D (uintptr)&base2 - (uintptr)&base1; > val =3D *((T *)((uintptr)base1 + i + offset)) >=20 > 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). >=20 > If we somehow get back a POINTER_PLUS that's where things go wrong. >=20 > 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). OK. Modrefs tracks base pointer for accesses and tries to prove that they are function parameters. This should immitate ivopts: void __attribute__ ((noinline)) set(int *a, unsigned long off) { *(int *)((unsigned long)a + off) =3D 1; } int test () { int a; int b =3D 0; set (&a, (unsigned long)&b - (unsigned long)&a); return b; } Here set gets following gimple at modref2 time: __attribute__((noinline))=20 void set (int * a, long unsigned int off) { long unsigned int a.0_1; long unsigned int _2; int * _3;=20 [local count: 1073741824]: a.0_1 =3D (long unsigned int) a_4(D); _2 =3D a.0_1 + off_5(D);=20 _3 =3D (int *) _2;=20 *_3 =3D 1;=20 return; } This is not pattern matched so modref does not think the access has a as a base: stores: Base 0: alias set 1 Ref 0: alias set 1 Every access While for: void __attribute__ ((noinline)) set(int *a, unsigned long off) { *(a+off/sizeof(int))=3D1; } we produce: __attribute__((noinline)) void set (int * a, long unsigned int off) { sizetype _1; int * _2; [local count: 1073741824]: _1 =3D off_3(D) & 18446744073709551612; _2 =3D a_4(D) + _1; *_2 =3D 1; return; } And this is understood: stores: Base 0: alias set 1 Ref 0: alias set 1 access: Parm 0 If we consider it correct to optimize out the conversion from and to pointer type, then I suppose any addition of pointer and integer which we do not see means that we need to give up on tracking base completely. I guess PTA gets around by tracking points-to set also for non-pointer types and consequently it also gives up on any such addition. But what we really get from relaxing this? >=20 > 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 ...). >=20 > > A quick fix would be to run IPA modref before ivopts, but I do not see = how such > > transformation can work with rest of alias analysis (PTA etc) >=20 > It does. Somewhere IPA modref interprets things wrongly, I didn't figure > out here though. I guess PTA gets around by tracking points-to set also for non-pointer types and consequently it also gives up on any such addition. I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts pointer_plus expression, but does not look through POINTER_PLUS. We can restrict it further, but tracking base pointer is quite useful, so it would be nice to not give up completely. Honza >=20 > --=20 > You are receiving this mail because: > You are on the CC list for the bug.=