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/94343] [10 Regression] invalid AVX512VL vpternlogd instruction emitted for -march=knl
Date: Mon, 30 Mar 2020 16:05:57 +0000	[thread overview]
Message-ID: <bug-94343-4-UHa1HI9eZE@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-94343-4@http.gcc.gnu.org/bugzilla/>

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

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

https://gcc.gnu.org/g:5abbfd3cd36342df530410033844584d8b85e187

commit r10-7460-g5abbfd3cd36342df530410033844584d8b85e187
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Mon Mar 30 18:05:01 2020 +0200

    i386: Fix up *one_cmplv*2* insn with avx512f [PR94343]

    This define_insn has two issues.
    One is that with -mavx512f -mno-avx512vl it can emit an AVX512VL-only insn
    - 128-bit or 256-bit EVEX encoded vpternlog{d,q}.
    Another one is that because there is no vpternlog{b,w}, we emit vpternlogd
    instead, but then we shouldn't pretend we support masking of that, because
    we don't.
    The first one can be fixed by forcing the use of %zmm* registers instead of
    %xmm* or %ymm* if AVX512F but not AVX512VL, like we do for a couple of
other
    insns (although that is primarily done in order to support %xmm16+ regs).
    But we need to make sure that in that case the input operand isn't memory,
    because while we can read and store the higher bits of registers, we don't
    want to read from memory more bytes than what we should read.

    A variant to these two if_then_else set attrs, condition in the output and
    larger condition would be 4 different define_insns (one with something like
    VI48_AVX512VL iterator, masking, no g modifiers and "vm" input constraint,
    another one with VI48_AVX iterator, !TARGET_AVX512VL in condition,
    no masking, g modifiers and "v" input constraint, one with VI12_AVX512VL
    iterator, no masking, no g modifiers and "vm" input constraint and last one
with
    VI12_AVX2 iterator, !TARGET_AVX512VL in condition, no masking, g modifiers
    and "v" input constraint, but I think having one pattern is shorter than
    that.

    2020-03-30  Jakub Jelinek  <jakub@redhat.com>

            PR target/94343
            * config/i386/sse.md (<mask_codefor>one_cmpl<mode>2<mask_name>): If
            !TARGET_AVX512VL, use 512-bit vpternlog and make sure the input
            operand is a register.  Don't enable masked variants for
V*[QH]Imode.

            * gcc.target/i386/avx512f-pr94343.c: New test.
            * gcc.target/i386/avx512vl-pr94343.c: New test.

  parent reply	other threads:[~2020-03-30 16:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-26 15:24 [Bug target/94343] New: " kretz at kde dot org
2020-03-26 15:39 ` [Bug target/94343] " marxin at gcc dot gnu.org
2020-03-26 15:58 ` jakub at gcc dot gnu.org
2020-03-26 16:34 ` hjl.tools at gmail dot com
2020-03-26 16:41 ` jakub at gcc dot gnu.org
2020-03-26 17:08 ` jakub at gcc dot gnu.org
2020-03-26 17:14 ` hjl.tools at gmail dot com
2020-03-26 17:52 ` jakub at gcc dot gnu.org
2020-03-26 17:59 ` jakub at gcc dot gnu.org
2020-03-26 19:30 ` kretz at kde dot org
2020-03-26 19:44 ` jakub at gcc dot gnu.org
2020-03-27  7:00 ` jbeulich at suse dot com
2020-03-27  7:07 ` jbeulich at suse dot com
2020-03-27  7:31 ` jbeulich at suse dot com
2020-03-27  8:45 ` jakub at gcc dot gnu.org
2020-03-27  9:11 ` jakub at gcc dot gnu.org
2020-03-27  9:17 ` jbeulich at suse dot com
2020-03-27  9:21 ` jakub at gcc dot gnu.org
2020-03-30 16:05 ` cvs-commit at gcc dot gnu.org [this message]
2020-03-30 16:06 ` jakub 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-94343-4-UHa1HI9eZE@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).