On 7/19/24 2:54 AM, demin.han wrote:
There are still some cases which can't utilize vx or vf after
last_combine pass.

1. integer comparison when imm isn't in range of [-16, 15]
2. float imm is 0.0
3. DI or DF mode under RV32

This patch fix above mentioned issues.

Tested on RV32 and RV64.

Signed-off-by: demin.han <demin....@starfivetech.com>
gcc/ChangeLog:

        * config/riscv/autovec.md: register_operand to nonmemory_operand
        * config/riscv/riscv-v.cc (get_cmp_insn_code): Select code according
     * to scalar_p
        (expand_vec_cmp): Generate scalar_p and transform op1
        * config/riscv/riscv.cc (riscv_const_insns): Add !FLOAT_MODE_P
     * constrain

gcc/testsuite/ChangeLog:

        * gcc.target/riscv/rvv/autovec/cmp/vcond-1.c: Fix and add test

Signed-off-by: demin.han <demin....@starfivetech.com>
---
V2 changes:
   1. remove unnecessary add_integer_operand and related code
   2. fix one format issue
   3. split patch and make it only related to vec cmp

  gcc/config/riscv/autovec.md                   |  2 +-
  gcc/config/riscv/riscv-v.cc                   | 57 +++++++++++--------
  gcc/config/riscv/riscv.cc                     |  2 +-
  .../riscv/rvv/autovec/cmp/vcond-1.c           | 48 +++++++++++++++-
  4 files changed, 82 insertions(+), 27 deletions(-)

diff --git a/gcc/config/riscv/autovec.md b/gcc/config/riscv/autovec.md
index d5793acc999..a7111172153 100644
--- a/gcc/config/riscv/autovec.md
+++ b/gcc/config/riscv/autovec.md
@@ -690,7 +690,7 @@ (define_expand "vec_cmp<mode><vm>"
    [(set (match_operand:<VM> 0 "register_operand")
        (match_operator:<VM> 1 "comparison_operator"
          [(match_operand:V_VLSF 2 "register_operand")
-          (match_operand:V_VLSF 3 "register_operand")]))]
+          (match_operand:V_VLSF 3 "nonmemory_operand")]))]
    "TARGET_VECTOR"
I'm still concerned about this. We generally want the expander's predicate to match what the insn can do. A "nonmemory_operand" is likely going to accept all kinds of things that we don't want. A tighter predicate seems more appropriate.

Also note that a define_expand is primarily used during initial RTL generation. What's more important from a code optimization standpoint is the define_insn patterns since that's what passes will test against for recognition.]

Jeff

Reply via email to