public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jeff Law <law@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/vendors/riscv/heads/gcc-13-with-riscv-opts)] RISC-V: Fold all the cond-move variants together Date: Wed, 22 Nov 2023 05:10:44 +0000 (GMT) [thread overview] Message-ID: <20231122051044.2DF9E3858C2B@sourceware.org> (raw) https://gcc.gnu.org/g:136b1f355092bff70396ecfe07cdd1386d2fd800 commit 136b1f355092bff70396ecfe07cdd1386d2fd800 Author: Maciej W. Rozycki <macro@embecosm.com> Date: Wed Nov 22 01:18:27 2023 +0000 RISC-V: Fold all the cond-move variants together Code in `riscv_expand_conditional_move' for Ventana and Zicond targets seems like bolted on as an afterthought rather than properly merged so as to handle all the cases together. Fold the existing code pieces together then (observing that for short forward branch targets no integer comparisons need to be canonicalized), letting T-Head targets produce branchless sequences for all the integer comparisons rather than for equality ones only, and preparing for the handling of floating-point comparisons here across all conditional-move targets. gcc/ * config/riscv/riscv.cc (riscv_expand_conditional_move): Unify conditional-move handling across all the relevant targets. (cherry picked from commit 413ebfd660793ce16f0e6173b38ad91cd2f0cf64) Diff: --- gcc/config/riscv/riscv.cc | 60 ++++++++++++++++++++--------------------------- 1 file changed, 26 insertions(+), 34 deletions(-) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc index cdd1a4f9e25..4424882ec3a 100644 --- a/gcc/config/riscv/riscv.cc +++ b/gcc/config/riscv/riscv.cc @@ -4119,35 +4119,9 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx cons, rtx alt) rtx_code code = GET_CODE (op); rtx op0 = XEXP (op, 0); rtx op1 = XEXP (op, 1); - bool need_eq_ne_p = false; - - if (TARGET_XTHEADCONDMOV - && GET_MODE_CLASS (mode) == MODE_INT - && (GET_MODE (op) == mode || GET_MODE (op) == E_VOIDmode) - && (GET_MODE (op0) == mode || CONST_INT_P (op0)) - && (GET_MODE (op1) == mode || CONST_INT_P (op1)) - && (code == EQ || code == NE)) - need_eq_ne_p = true; - - if (need_eq_ne_p - || (TARGET_SFB_ALU && GET_MODE (op0) == word_mode)) - { - riscv_emit_int_compare (&code, &op0, &op1, need_eq_ne_p); - rtx cond = gen_rtx_fmt_ee (code, GET_MODE (op0), op0, op1); - - /* The expander is a bit loose in its specification of the true - arm of the conditional move. That allows us to support more - cases for extensions which are more general than SFB. But - does mean we need to force CONS into a register at this point. */ - cons = force_reg (mode, cons); - /* With XTheadCondMov we need to force ALT into a register too. */ - alt = force_reg (mode, alt); - emit_insn (gen_rtx_SET (dest, gen_rtx_IF_THEN_ELSE (mode, - cond, cons, alt))); - return true; - } - else if (TARGET_ZICOND_LIKE - && GET_MODE_CLASS (mode) == MODE_INT) + + if ((TARGET_ZICOND_LIKE && GET_MODE_CLASS (mode) == MODE_INT) + || TARGET_SFB_ALU || TARGET_XTHEADCONDMOV) { machine_mode mode0 = GET_MODE (op0); machine_mode mode1 = GET_MODE (op1); @@ -4161,9 +4135,11 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx cons, rtx alt) return false; /* Canonicalize the comparison. It must be an equality comparison - of integer operands. If it isn't, then emit an SCC instruction + of integer operands, or with SFB it can be any comparison of + integer operands. If it isn't, then emit an SCC instruction so that we can then use an equality comparison against zero. */ - if (!equality_operator (op, VOIDmode) || !INTEGRAL_MODE_P (mode0)) + if ((!TARGET_SFB_ALU && !equality_operator (op, VOIDmode)) + || !INTEGRAL_MODE_P (mode0)) { bool *invert_ptr = nullptr; bool invert = false; @@ -4195,10 +4171,26 @@ riscv_expand_conditional_move (rtx dest, rtx op, rtx cons, rtx alt) op1 = XEXP (op, 1); } + if (TARGET_SFB_ALU || TARGET_XTHEADCONDMOV) + { + riscv_emit_int_compare (&code, &op0, &op1, !TARGET_SFB_ALU); + rtx cond = gen_rtx_fmt_ee (code, GET_MODE (op0), op0, op1); + + /* The expander is a bit loose in its specification of the true + arm of the conditional move. That allows us to support more + cases for extensions which are more general than SFB. But + does mean we need to force CONS into a register at this point. */ + cons = force_reg (mode, cons); + /* With XTheadCondMov we need to force ALT into a register too. */ + alt = force_reg (mode, alt); + emit_insn (gen_rtx_SET (dest, gen_rtx_IF_THEN_ELSE (mode, cond, + cons, alt))); + return true; + } /* 0, reg or 0, imm */ - if (cons == CONST0_RTX (mode) - && (REG_P (alt) - || (CONST_INT_P (alt) && alt != CONST0_RTX (mode)))) + else if (cons == CONST0_RTX (mode) + && (REG_P (alt) + || (CONST_INT_P (alt) && alt != CONST0_RTX (mode)))) { riscv_emit_int_compare (&code, &op0, &op1, true); rtx cond = gen_rtx_fmt_ee (code, GET_MODE (op0), op0, op1);
reply other threads:[~2023-11-22 5:10 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20231122051044.2DF9E3858C2B@sourceware.org \ --to=law@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).