public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/110788] New: Spilling to mask register for GPR vec_duplicate Date: Mon, 24 Jul 2023 08:40:29 +0000 [thread overview] Message-ID: <bug-110788-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110788 Bug ID: 110788 Summary: Spilling to mask register for GPR vec_duplicate Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- double a[1024], b[1024]; void foo (int n) { for (int i = 0; i < n; ++i) a[i] = b[i] * 3.; } compiled with -O3 -march=cascadelake --param vect-partial-vector-usage=2 produces the inner loop .L3: vmovapd b(%rax), %ymm0{%k1} movl %edx, %ecx subl $4, %edx kmovw %edx, %k0 vmulpd %ymm3, %ymm0, %ymm1{%k1}{z} vmovapd %ymm1, a(%rax){%k1} vpbroadcastmw2d %k0, %xmm1 addq $32, %rax vpcmpud $6, %xmm2, %xmm1, %k1 cmpw $4, %cx ja .L3 where we implement the splat of %edx as kmovw %edx, %k0 vpbroadcastmw2d %k0, %xmm1 instead of vpbroadcastw %edx, %xmm1 we expand to (insn 14 13 15 (set (reg:V4SI 96) (vec_duplicate:V4SI (reg:SI 93 [ _27 ]))) 8167 {*avx512vl_vec_dup_gprv4si} (nil)) but at IRA time we instead match that do (insn 14 13 15 3 (set (reg:V4SI 96) (vec_duplicate:V4SI (zero_extend:SI (subreg:HI (reg/v:SI 95 [ n ]) 0)))) 8247 {avx512cd_maskw_vec_dupv4si} (expr_list:REG_DEAD (reg/v:SI 95 [ n ]) (nil))) where combine created this via Trying 13 -> 14: 13: r93:SI=zero_extend(r95:SI#0) REG_DEAD r95:SI 14: r96:V4SI=vec_duplicate(r93:SI) REG_DEAD r93:SI Successfully matched this instruction: (set (reg:V4SI 96) (vec_duplicate:V4SI (zero_extend:SI (subreg:HI (reg/v:SI 95 [ n ]) 0)))) allowing combination of insns 13 and 14 original costs 4 + 4 = 8 replacement cost 4 but it didn't anticipate that reg 95 could be allocated to a GPR? The vectorizer uses an unsigned short IV for the loop, that's possibly sub-optimal in this case but important in others. I suppose it could also be a missed optimization in REE since I think the HImode regs should already be zero-extended?
next reply other threads:[~2023-07-24 8:40 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-24 8:40 rguenth at gcc dot gnu.org [this message] 2023-07-27 7:02 ` [Bug target/110788] " crazylht at gmail dot com 2023-07-27 7:09 ` crazylht at gmail dot com 2023-07-27 11:29 ` ubizjak at gmail dot com 2023-07-27 13:55 ` crazylht at gmail dot com 2023-07-28 2:07 ` cvs-commit at gcc dot gnu.org 2023-07-28 2:30 ` crazylht at gmail dot com 2023-11-30 10:51 ` liuhongt 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-110788-4@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).