From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE6E03858D20; Mon, 26 Jun 2023 08:44:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE6E03858D20 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1687769041; bh=ovnLcSRZiJTts0sh0rkxVvaImZgi32oeICgln+NPtJg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=VlA4JYOsjfXKtXupqmfEdQrAkNq+jzYK9LMo0CxNAQ5vLQ9IlAKppdNKkdNQyUyNx dH//A8ZQPIJPLzB1CFZtU52p9VLopebnQnyosJUjEYnmOOKsbxn1/wOKgE5z03okSc 5l+0kGH6aRKOB1GUZPlf/V2wJI3tjFRbTwtw6DaE= From: "crazylht at gmail dot com" 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 08:44:01 +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: crazylht at gmail dot com 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 #15 from Hongtao.liu --- (In reply to rguenther@suse.de from comment #10) > On Sun, 25 Jun 2023, crazylht at gmail dot com wrote: >=20 > > 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 mem= ory > > dest, so I guess no need to use UNSPEC for maskstore? >=20 > A maskstore now looks like >=20 > (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} >=20 > 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. >=20 In my understanding, use whole size for trap analysis is suboptimal but saf= e, if whole size access is safe, mask_load/store must be safe. But it could be suboptimal when whole size access can trap but mask_load/store won't, but we should accept that suboptimal since mask is not always known. I didn't find such rule in rtx_addr_can_trap_p, but only known_subrange_p. /* If the pointer based access is bigger than the variable they cannot alias. This is similar to the check below where we use TBAA to increase the size of the pointer based access based on the dynamic type of a containing object we can infer from it. */ poly_int64 dsize2; if (known_size_p (size1) && poly_int_tree_p (DECL_SIZE (base2), &dsize2) && known_lt (dsize2, size1)) return false;=