public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "crazylht at gmail dot com" <gcc-bugzilla@gcc.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: Mon, 26 Jun 2023 08:44:01 +0000	[thread overview]
Message-ID: <bug-110237-4-ixzoIPdY9k@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-110237-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237

--- Comment #15 from Hongtao.liu <crazylht at gmail dot com> ---
(In reply to rguenther@suse.de from comment #10)
> On Sun, 25 Jun 2023, crazylht at gmail dot com wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110237
> > 
> > --- Comment #9 from Hongtao.liu <crazylht at gmail dot com> ---
> > 
> > > 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.
> > > 
> > 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 
> {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.
> 

In my understanding, use whole size for trap analysis is suboptimal but safe,
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;

  parent reply	other threads:[~2023-06-26  8:44 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-13 13:50 [Bug rtl-optimization/110237] New: " rguenth at gcc dot gnu.org
2023-06-14 11:02 ` [Bug rtl-optimization/110237] " amonakov at gcc dot gnu.org
2023-06-14 12:09 ` rguenth at gcc dot gnu.org
2023-06-20  9:52 ` rguenth at gcc dot gnu.org
2023-06-20 11:35 ` crazylht at gmail dot com
2023-06-20 12:20 ` rguenther at suse dot de
2023-06-20 16:05 ` crazylht at gmail dot com
2023-06-21  5:48 ` crazylht at gmail dot com
2023-06-21  7:33 ` rguenth at gcc dot gnu.org
2023-06-25  4:06 ` crazylht at gmail dot com
2023-06-26  7:41 ` rguenther at suse dot de
2023-06-26  7:58 ` amonakov at gcc dot gnu.org
2023-06-26  8:07 ` rguenther at suse dot de
2023-06-26  8:22 ` amonakov at gcc dot gnu.org
2023-06-26  8:35 ` rguenther at suse dot de
2023-06-26  8:44 ` crazylht at gmail dot com [this message]
2023-06-26  8:54 ` amonakov at gcc dot gnu.org
2023-06-26 11:14 ` rguenther at suse dot de
2023-06-26 18:19 ` amonakov at gcc dot gnu.org
2023-06-27  6:53 ` rguenther at suse dot de
2023-06-27  7:30 ` cvs-commit at gcc dot gnu.org
2023-06-27  9:50 ` amonakov at gcc dot gnu.org
2023-06-27 10:03 ` rguenther at suse dot de
2023-06-29  1:27 ` cvs-commit at gcc dot gnu.org
2023-06-29  1:28 ` cvs-commit at gcc dot gnu.org
2023-06-29  1:29 ` cvs-commit at gcc dot gnu.org
2023-11-27 12:39 ` rdapp at gcc dot gnu.org
2023-11-29 12:26 ` cvs-commit at gcc dot gnu.org
2023-11-29 12:27 ` rguenth at gcc dot gnu.org

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-110237-4-ixzoIPdY9k@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).