From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 0DB693858D1E; Fri, 11 Feb 2022 09:25:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0DB693858D1E From: "avieira at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/104498] New: Alias attribute being ignored by scheduler Date: Fri, 11 Feb 2022 09:25:42 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: unknown X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: avieira at gcc dot gnu.org 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: 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 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2022 09:25:43 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D104498 Bug ID: 104498 Summary: Alias attribute being ignored by scheduler Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: avieira at gcc dot gnu.org Target Milestone: --- Whilst working on a tuning structure I saw a correctness regression that I believe is a result of the alias attribute not working properly. You can reproduce it using an existing tuning for AArch64 using: gcc -O2 src/gcc/gcc/testsuite/gcc.c-torture/execute/alias-2.c -S -mtune=3Dcortex-a34 This will lead to the 'a[off] =3D 2' store being moved after the b load in 'b[off] !=3D 2'. In RTL: (insn 23 18 19 2 (set (reg:SI 110 [ b[off.0_1] ]) (mem:SI (plus:DI (mult:DI (reg:DI 99 [ off.0_1 ]) (const_int 4 [0x4])) (reg/f:DI 97)) [1 b[off.0_1]+0 S4 A32])) "gcc/gcc/testsuite/gcc.c-torture/execute/alias-2.c":10:6 52 {*movsi_aarch64} (expr_list:REG_DEAD (reg:DI 99 [ off.0_1 ]) (expr_list:REG_DEAD (reg/f:DI 97) (nil)))) (insn 19 23 24 2 (set (mem:SI (plus:DI (mult:DI (reg:DI 99 [ off.0_1 ]) (const_int 4 [0x4])) (reg/f:DI 104)) [1 a[off.0_1]+0 S4 A32]) (reg:SI 106)) "gcc/gcc/testsuite/gcc.c-torture/execute/alias-2.c":9= :9 52 {*movsi_aarch64} (expr_list:REG_DEAD (reg:SI 106) (expr_list:REG_DEAD (reg/f:DI 104) (nil)))) After some debugging I found that true_dependence returns false for these t= wo memory accesses because base_alias_check sees they have different base obje= cts ('a' and 'b') and deduces they can't alias based on that, without realising= 'b' isn't an actual base object but an alias to 'a'. I think we should make it = so that at expand pointers to 'b' get 'a' as a base object.=