public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/87767] Missing AVX512 memory broadcast for constant vector Date: Thu, 03 Sep 2020 09:31:40 +0000 [thread overview] Message-ID: <bug-87767-4-PIQ5LjP00U@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-87767-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87767 --- Comment #12 from Jakub Jelinek <jakub at gcc dot gnu.org> --- What I mean is that we should try to simplify the md file, instead of adding hundreds of new *_bcst patterns. We have e.g. (define_insn "*<plusminus_insn><mode>3" [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v") (plusminus:VI_AVX2 (match_operand:VI_AVX2 1 "vector_operand" "<comm>0,v") (match_operand:VI_AVX2 2 "vector_operand" "xBm,vm")))] "TARGET_SSE2 && ix86_binary_operator_ok (<CODE>, <MODE>mode, operands)" "@ p<plusminus_mnemonic><ssemodesuffix>\t{%2, %0|%0, %2} vp<plusminus_mnemonic><ssemodesuffix>\t{%2, %1, %0|%0, %1, %2}" [(set_attr "isa" "noavx,avx") (set_attr "type" "sseiadd") (set_attr "prefix_data16" "1,*") (set_attr "prefix" "orig,vex") (set_attr "mode" "<sseinsnmode>")]) (define_insn "*sub<mode>3_bcst" [(set (match_operand:VI48_AVX512VL 0 "register_operand" "=v") (minus:VI48_AVX512VL (match_operand:VI48_AVX512VL 1 "register_operand" "v") (vec_duplicate:VI48_AVX512VL (match_operand:<ssescalarmode> 2 "memory_operand" "m"))))] "TARGET_AVX512F && ix86_binary_operator_ok (MINUS, <MODE>mode, operands)" "vpsub<ssemodesuffix>\t{%2<avx512bcst>, %1, %0|%0, %1, %2<avx512bcst>}" [(set_attr "type" "sseiadd") (set_attr "prefix" "evex") (set_attr "mode" "<sseinsnmode>")]) What I meant is we could have just: (define_insn "*<plusminus_insn><mode>3" [(set (match_operand:VI_AVX2 0 "register_operand" "=x,v") (plusminus:VI_AVX2 (match_operand:VI_AVX2 1 "vector_bcst_operand" "<comm>0,v") (match_operand:VI_AVX2 2 "vector_bcst_operand" "xBm,vBb")))] "TARGET_SSE2 && ix86_binary_operator_ok (<CODE>, <MODE>mode, operands)" "@ p<plusminus_mnemonic><ssemodesuffix>\t{%2, %0|%0, %2} vp<plusminus_mnemonic><ssemodesuffix>\t{%2, %1, %0|%0, %1, %2}" [(set_attr "isa" "noavx,avx") (set_attr "type" "sseiadd") (set_attr "prefix_data16" "1,*") (set_attr "prefix" "orig,vex") (set_attr "mode" "<sseinsnmode>")]) where vector_bcst_operand is either vector_operand, or for TARGET_AVX512F a VEC_DUPLICATE of the right mode with a MEM inside of it with the element mode of the VEC_DUPLICATE mode, similarly Bb constraint is either m, or for TARGET_AVX512F also again the VEC_DUPLICATE with MEM inside of it, and that ix86_binary_operator_ok would treat a VEC_DUPLICATE wrapping MEM the same as MEM (in particular ensure one e.g. doesn't have one VEC_DUPLICATE and one MEM operand, or two VEC_DUPLICATE operands) and that the output code would handle emitting an operand with VEC_DUPLICATE of a MEM properly. Or perhaps the constraint there could be just for the broadcast and one could write vmBb. Still, I think the predicate needs to be accurate, i.e. for some instructions we want e.g. vector_operand or TARGET_AVX512F and bcst_mem_operand, for others vector_operand or TARGET_AVX512VL and bcst_mem_operand etc. Anyway, if we go down this route, might be best to handle just a couple of patterns, then ask for review and see what Kirill (or if Uros would be interested) think about it and only later convert more.
next prev parent reply other threads:[~2020-09-03 9:31 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <bug-87767-4@http.gcc.gnu.org/bugzilla/> 2020-07-13 7:05 ` crazylht at gmail dot com 2020-09-03 8:11 ` cvs-commit at gcc dot gnu.org 2020-09-03 8:30 ` crazylht at gmail dot com 2020-09-03 8:37 ` jakub at gcc dot gnu.org 2020-09-03 9:06 ` crazylht at gmail dot com 2020-09-03 9:31 ` jakub at gcc dot gnu.org [this message] 2020-09-04 15:52 ` crazylht at gmail dot com 2020-09-04 15:56 ` crazylht at gmail dot com 2020-09-08 4:28 ` crazylht at gmail dot com 2020-09-09 17:06 ` vmakarov at gcc dot gnu.org 2020-10-22 2:29 ` cvs-commit at gcc dot gnu.org 2020-10-22 2:29 ` cvs-commit at gcc dot gnu.org 2021-07-01 15:11 ` cvs-commit at gcc dot gnu.org 2021-07-21 14:56 ` hjl.tools at gmail dot com 2021-07-27 20:24 ` hjl.tools at gmail dot com 2021-09-18 5:03 ` cvs-commit 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-87767-4-PIQ5LjP00U@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: linkBe 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).