From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 8DBBC3858D37; Mon, 26 Jun 2023 07:41:13 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8DBBC3858D37 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687765273; bh=UwDWnr0fyfsbdrqTQpuSfsgcHgMuypRJIz6ohqWzcOE=; h=From:To:Subject:Date:In-Reply-To:References:From; b=HmP9oqMpjlVeQ26FtS6ai+MU01ogjt/DKp1EuSKoB082PWJBT/Uns3JB4TLcmRS7j HHzQ1dFL8Al1Wi6sC8K4MU85n9VBK/pXIptlvqm+FXeIgc1AYlQiNtVttc7V9pVxFm eLan+nu1QCkf3MYs52EGx9Vh/QHrxh+9ONndqa0E= From: "rguenther at suse dot de" 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: Mon, 26 Jun 2023 07:41:12 +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: rguenther at suse dot de 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: 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 --- Comment #10 from rguenther at suse dot de --- On Sun, 25 Jun 2023, crazylht at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D110237 >=20 > --- Comment #9 from Hongtao.liu --- >=20 > > 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. > >=20 > Note maskstore won't optimized to vpblendd since it doesn't support memory > dest, so I guess no need to use UNSPEC for maskstore? A maskstore now looks like (insn 31 30 32 5 (set (mem:V8DF (plus:DI (reg/v/f:DI 108 [ a ]) (reg:DI 90 [ ivtmp.28 ])) [1 S64 A64]) (vec_merge:V8DF (reg:V8DF 115 [ vect__9.14 ]) (mem:V8DF (plus:DI (reg/v/f:DI 108 [ a ]) (reg:DI 90 [ ivtmp.28 ])) [1 S64 A64]) (reg:QI 100 [ loop_mask_57 ]))) "t.c":6:14 1957=20 {avx512f_storev8df_mask} that appears as a full read and a full store which means earlier stores to the masked part could be elided rightfully by RTL DSE at least. If there's any RTL analysis about whether a conditional load could trap then for example a full V8DF load from the same address that's currently conditional but after the above could be analyzed as safe to be scheduled speculatively and unconditional while it would not be safe as it could trap. I think the DSE issue is real and it should be easy to create a testcase like void foo (double *d, int mask) { d[5] =3D 1.; _intrinsic_for_mask_store (d, some-val, mask); } call that with lane 5 masked and check for d[5] =3D 1. preserved. I think RTL DSE will remove that store.=