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 target/99563] [10 Regression] Code miscompilation caused by _mm256_zeroupper()
Date: Fri, 19 Mar 2021 23:30:41 +0000	[thread overview]
Message-ID: <bug-99563-4-6iKHIUhThw@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-99563-4@http.gcc.gnu.org/bugzilla/>

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

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:788da80413551fe1a1411c700864640b590dcfc5

commit r10-9486-g788da80413551fe1a1411c700864640b590dcfc5
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Tue Mar 16 11:16:15 2021 +0100

    i386: Fix up _mm256_vzeroupper() handling [PR99563]

    My r10-6451-gb7b3378f91c0641f2ef4d88db22af62a571c9359 fix for
    vzeroupper vs. ms ABI apparently broke the explicit vzeroupper handling
    when the implicit vzeroupper handling is disabled.
    The epilogue_completed splitter for vzeroupper now adds clobbers for all
    registers which don't have explicit sets in the pattern and the sets are
    added during vzeroupper pass.  Before my changes, for explicit user
    vzeroupper, we just weren't modelling its effects at all, it was just
    unspec that didn't tell that it clobbers the upper parts of all XMM <
%xmm16
    registers.  But now the splitter will even for those add clobbers and as
    it has no sets, it will add clobbers for all registers, which means
    we optimize away anything that lived across that vzeroupper.

    The vzeroupper pass has two parts, one is the mode switching that computes
    where to put the implicit vzeroupper calls and puts them there, and then
    another that uses df to figure out what sets to add to all the vzeroupper.
    The former part should be done only under the conditions we have in the
    gate, but the latter as this PR shows needs to happen either if we perform
    the implicit vzeroupper additions, or if there are (or could be) any
    explicit vzeroupper instructions.  As that function does df_analyze and
    walks the whole IL, I think it would be too expensive to run it always
    whenever TARGET_AVX, so this patch remembers if we've expanded at least
    one __builtin_ia32_vzeroupper in the function and runs that part of the
    vzeroupper pass both when the old condition is true or when this new
    flag is set.

    2021-03-16  Jakub Jelinek  <jakub@redhat.com>

            PR target/99563
            * config/i386/i386.h (struct machine_function): Add
            has_explicit_vzeroupper bitfield.
            * config/i386/i386-expand.c (ix86_expand_builtin): Set
            cfun->machine->has_explicit_vzeroupper when expanding
            IX86_BUILTIN_VZEROUPPER.
            * config/i386/i386-features.c (rest_of_handle_insert_vzeroupper):
            Do the mode switching only when TARGET_VZEROUPPER, expensive
            optimizations turned on and not optimizing for size.
            (pass_insert_vzeroupper::gate): Enable even when
            cfun->machine->has_explicit_vzeroupper is set.

            * gcc.target/i386/avx-pr99563.c: New test.

    (cherry picked from commit 82085eb3d44833bd1557fdd932c4738d987f559d)

  parent reply	other threads:[~2021-03-19 23:30 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-12 16:36 [Bug target/99563] New: " andysem at mail dot ru
2021-03-12 17:39 ` [Bug target/99563] [10/11 Regression] " jakub at gcc dot gnu.org
2021-03-15 12:51 ` jakub at gcc dot gnu.org
2021-03-16 10:17 ` cvs-commit at gcc dot gnu.org
2021-03-16 19:26 ` [Bug target/99563] [10 " jakub at gcc dot gnu.org
2021-03-16 20:12 ` andysem at mail dot ru
2021-03-19 23:30 ` cvs-commit at gcc dot gnu.org [this message]
2021-03-20  8:10 ` jakub at gcc dot gnu.org
2021-03-20  8:29 ` andysem at mail dot ru

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-99563-4-6iKHIUhThw@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).