public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Michael Meissner <meissner@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/users/meissner/heads/work082)] Improve vsx_extract_<mode> Date: Wed, 23 Mar 2022 16:45:22 +0000 (GMT) [thread overview] Message-ID: <20220323164522.F3A353857809@sourceware.org> (raw) https://gcc.gnu.org/g:df5e4b1f79a2efc54b211e11177f66ef9d360645 commit df5e4b1f79a2efc54b211e11177f66ef9d360645 Author: Michael Meissner <meissner@linux.ibm.com> Date: Wed Mar 23 12:45:02 2022 -0400 Improve vsx_extract_<mode> In looking at PR target/99293, I noticed that the code in vsx_extract_<mode> could be improved. When the element being extracted is the element in the upper 64-bits, we should do an insn_split to convert this to a simple move. This would allow the post reload passes to eliminate the move completely. The code was written before we moved to LRA for register allocation and it restricted the target register to just traditional floating point registers. I have changed this to target any VSX register. The insn type attribute was incorrect in that it used "mfvsr" instead of "vecperm" when a xxpermdi would be generated. Also, when a "mvfsrld" would be generated, the type should be "mfvsr". 2022-03-22 Michael Meissner <meissner@linux.ibm.com> gcc/ PR target/99392 * config/rs6000/rs6000.md (vsx_extract_<mode>): Split extracts that are just a move to being a move insn. Use the correct insn type for the alternatives. (insn splitter for vsx_extract_<mode>): Add new splitter. Diff: --- gcc/config/rs6000/vsx.md | 49 +++++++++++++++++++++--------------------------- 1 file changed, 21 insertions(+), 28 deletions(-) diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md index a1c95c61b2e..031d2560265 100644 --- a/gcc/config/rs6000/vsx.md +++ b/gcc/config/rs6000/vsx.md @@ -3397,46 +3397,27 @@ ;; Optimize cases were we can do a simple or direct move. ;; Or see if we can avoid doing the move at all -;; There are some unresolved problems with reload that show up if an Altivec -;; register was picked. Limit the scalar value to FPRs for now. - (define_insn "vsx_extract_<mode>" - [(set (match_operand:<VS_scalar> 0 "gpc_reg_operand" "=d, d, wr, wr") + [(set (match_operand:<VS_scalar> 0 "gpc_reg_operand" "=wa, wa, r, r") (vec_select:<VS_scalar> - (match_operand:VSX_D 1 "gpc_reg_operand" "wa, wa, wa, wa") + (match_operand:VSX_D 1 "gpc_reg_operand" "wa, wa, wa, wa") (parallel - [(match_operand:QI 2 "const_0_to_1_operand" "wD, n, wD, n")])))] + [(match_operand:QI 2 "const_0_to_1_operand" "wD, n, wD, n")])))] "VECTOR_MEM_VSX_P (<MODE>mode)" { int element = INTVAL (operands[2]); - int op0_regno = REGNO (operands[0]); - int op1_regno = REGNO (operands[1]); + int op0_regno = reg_or_subregno (operands[0]); + int op1_regno = reg_or_subregno (operands[1]); int fldDM; gcc_assert (IN_RANGE (element, 0, 1)); gcc_assert (VSX_REGNO_P (op1_regno)); if (element == VECTOR_ELEMENT_SCALAR_64BIT) - { - if (op0_regno == op1_regno) - return ASM_COMMENT_START " vec_extract to same register"; - - else if (INT_REGNO_P (op0_regno) && TARGET_DIRECT_MOVE - && TARGET_POWERPC64) - return "mfvsrd %0,%x1"; - - else if (FP_REGNO_P (op0_regno) && FP_REGNO_P (op1_regno)) - return "fmr %0,%1"; - - else if (VSX_REGNO_P (op0_regno)) - return "xxlor %x0,%x1,%x1"; - - else - gcc_unreachable (); - } + return "#"; - else if (element == VECTOR_ELEMENT_MFVSRLD_64BIT && INT_REGNO_P (op0_regno) - && TARGET_P9_VECTOR && TARGET_POWERPC64 && TARGET_DIRECT_MOVE) + if (INT_REGNO_P (op0_regno) && TARGET_P9_VECTOR && TARGET_POWERPC64 + && TARGET_DIRECT_MOVE) return "mfvsrld %0,%x1"; else if (VSX_REGNO_P (op0_regno)) @@ -3451,9 +3432,21 @@ else gcc_unreachable (); } - [(set_attr "type" "veclogical,mfvsr,mfvsr,vecperm") + [(set_attr "type" "*,vecperm,mfvsr,mfvsr") (set_attr "isa" "*,*,p8v,p9v")]) +;; Convert extracting the element in the upper 64-bit bits to just a move. +(define_split + [(set (match_operand:<VS_scalar> 0 "gpc_reg_operand") + (vec_select:<VS_scalar> + (match_operand:VSX_D 1 "gpc_reg_operand") + (parallel [(match_operand:QI 2 "vsx_scalar_64bit")])))] + "VECTOR_MEM_VSX_P (<MODE>mode) && reload_completed" + [(set (match_dup 0) (match_dup 3))] +{ + operands[3] = gen_rtx_REG (<VS_scalar>mode, reg_or_subregno (operands[1])); +}) + ;; Optimize extracting a single scalar element from memory. (define_insn_and_split "*vsx_extract_<P:mode>_<VSX_D:mode>_load" [(set (match_operand:<VS_scalar> 0 "register_operand" "=wa,wr")
next reply other threads:[~2022-03-23 16:45 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2022-03-23 16:45 Michael Meissner [this message] 2022-03-23 23:32 Michael Meissner 2022-03-24 16:51 Michael Meissner
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=20220323164522.F3A353857809@sourceware.org \ --to=meissner@gcc.gnu.org \ --cc=gcc-cvs@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).