From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 940D93858C74; Wed, 21 Jun 2023 07:33:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 940D93858C74 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687332838; bh=VhYuOT86OxNxjKQYaOEqDCE/xcLjBZwqLNMvol9Mkqo=; h=From:To:Subject:Date:In-Reply-To:References:From; b=S/al4ac0MxhcKtZy3hPEMF4R6eq0HzX5/tQxVAOTW07DqSEhnyJgrKioR2WimeIMM IY5E2DYDW6ANx1Lf1uJs5jsRmw3fXW83QDdMUVAWDJpu0NeaMmE+gDDkL9NOSrv1nP x6VDq1ePdPo7xtwnXprYfVUs1Lvx/FWFfbJyuOUw= From: "rguenth at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/110237] gcc.dg/torture/pr58955-2.c is miscompiled by RTL scheduling after reload Date: Wed, 21 Jun 2023 07:33:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: rtl-optimization X-Bugzilla-Version: 14.0 X-Bugzilla-Keywords: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: rguenth at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to bug_status 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=3D110237 Richard Biener changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot = gnu.org Status|NEW |ASSIGNED --- Comment #8 from Richard Biener --- (In reply to Hongtao.liu from comment #7) > > So it looks like a generic problem and better to be handled in > > expand_partial_{load, store}_optab_fn? >=20 > There're many other places with assumption MEM_SIZE is equal to MODE_SIZE > even !MEM_SIZE_KNOWN_P, .i.e. ao_ref_base will rewrite size to MODE_SIZE. Yes, that's because MEM_EXPR isn't really correct ... I guess we could work around that in ao_ref_from_mem but expand_partial_store_optab_fn is wrong in setting that. There's no "partial memory" MEM, and AFAIK the memory attributes are only additional info and ignoring them is valid, so indeed a pass could at least interpret inputs and outputs in mode size even when UNSPECs are involved. But it must not(?) interpret them as must uses or kills? I also think that MEM_SIZE is really only relevant for BLKmode MEMs, MEM_OFFSET is only relevant for interpreting MEM_EXPR. Clearing MEM_EXPR and MEM_SIZE results in an ICE: #0 fancy_abort (file=3D0x31ce278 "/space/rguenther/src/gcc11queue/gcc/rtlanal.cc", line=3D469,=20 function=3D0x31d0560 , poly_int<1u, long>, machine_mode, bool)::__FUNCTION__> "rtx_addr_can_trap_p_1") at /space/rguenther/src/gcc11queue/gcc/diagnostic.cc:2232 #1 0x000000000158b62b in rtx_addr_can_trap_p_1 (x=3D0x7ffff6d51798, offset= =3D..., size=3D..., mode=3DE_V16SImode, unaligned_mems=3Dfalse) at /space/rguenther/src/gcc11queue/gcc/rtlanal.cc:467 #2 0x0000000001591a2d in may_trap_p_1 (x=3D0x7ffff6d51780, flags=3D0) at /space/rguenther/src/gcc11queue/gcc/rtlanal.cc:3160 #3 0x0000000001591f64 in may_trap_p (x=3D0x7ffff6d51780) at /space/rguenther/src/gcc11queue/gcc/rtlanal.cc:3283 #4 0x00000000015f32e6 in simplify_context::simplify_ternary_operation (this=3D0x7fffffffcd28, code=3DVEC_MERGE, mode=3DE_V16SImode,=20 op0_mode=3DE_V16SImode, op0=3D0x7ffff6e21d90, op1=3D0x7ffff6d51780, op2=3D0x7ffff6d51108) at /space/rguenther/src/gcc11queue/gcc/simplify-rtx.cc:7040 #5 0x0000000000f590c7 in simplify_ternary_operation (code=3DVEC_MERGE, mode=3DE_V16SImode, op0_mode=3DE_V16SImode, op0=3D0x7ffff6e21d90,=20 op1=3D0x7ffff6d51780, op2=3D0x7ffff6d51108) at /space/rguenther/src/gcc11queue/gcc/rtl.h:3498 (gdb) p debug_rtx (op1) (mem:V16SI (plus:DI (reg/f:DI 113) (reg:DI 90 [ _22 ])) [1 A32]) where I have only preserved MEM_ALIAS_SET and MEM_ALIGN. It insists on knowing the MEMs size if it's not BLKmode or VOIDmode. Indeed from the mode we can derived its size. So we can simply clear only MEM_EXPR (and MEM_OFFSET), that cuts off the problematic part of alias analysis. Together with UNSPEC this might be enough to fix things. I'm going to test such a patch and seek for feedback on the mailing list.=