public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <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: Wed, 29 Nov 2023 12:26:58 +0000	[thread overview]
Message-ID: <bug-110237-4-hqI6AN6Vrl@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 #27 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:b09b879e4e9cc24a5d2b0344c1930020c218a104

commit r14-5964-gb09b879e4e9cc24a5d2b0344c1930020c218a104
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Jun 21 09:31:30 2023 +0200

    middle-end/110237 - wrong MEM_ATTRs for partial loads/stores

    The following addresses a miscompilation by RTL scheduling related
    to the representation of masked stores.  For that we have

    (insn 38 35 39 3 (set (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ]
[90])
                    (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] 
<var_decl 0x7ffff6e28d80 b>)
                            (const_int -4 [0xfffffffffffffffc])))) [1 MEM
<vector(16) int> [(int *)vectp_b.12_28]+0 S64 A32])
            (vec_merge:V16SI (reg:V16SI 20 xmm0 [118])
                (mem:V16SI (plus:DI (reg:DI 40 r12 [orig:90 _22 ] [90])
                        (const:DI (plus:DI (symbol_ref:DI ("b") [flags 0x2] 
<var_decl 0x7ffff6e28d80 b>)
                                (const_int -4 [0xfffffffffffffffc])))) [1 MEM
<vector(16) int> [(int *)vectp_b.12_28]+0 S64 A32])

    and specifically the memory attributes

      [1 MEM <vector(16) int> [(int *)vectp_b.12_28]+0 S64 A32]

    are problematic.  They tell us the instruction stores and reads a full
    vector which it if course does not.  There isn't any good MEM_EXPR
    we can use here (we lack a way to just specify a pointer and restrict
    info for example), and since the MEMs have a vector mode it's
    difficult in general as passes do not need to look at the memory
    attributes at all.

    The easiest way to avoid running into the alias analysis problem is
    to scrap the MEM_EXPR when we expand the internal functions for
    partial loads/stores.  That avoids the disambiguation we run into
    which is realizing that we store to an object of less size as
    the size of the mode we appear to store.

    After the patch we see just

      [1  S64 A32]

    so we preserve the alias set, the alignment and the size (the size
    is redundant if the MEM insn't BLKmode).  That's still not good
    in case the RTL alias oracle would implement the same
    disambiguation but it fends off the gimple one.

    This fixes gcc.dg/torture/pr58955-2.c when built with AVX512
    and --param=vect-partial-vector-usage=1.

            PR middle-end/110237
            * internal-fn.cc (expand_partial_load_optab_fn): Clear
            MEM_EXPR and MEM_OFFSET.
            (expand_partial_store_optab_fn): Likewise.

  parent reply	other threads:[~2023-11-29 12:27 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
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 [this message]
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-hqI6AN6Vrl@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).