> diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md > index 718b4bd77df..f67bff0940f 100644 > --- a/gcc/config/riscv/constraints.md > +++ b/gcc/config/riscv/constraints.md > @@ -35,6 +35,17 @@ > > ;; General constraints > > +(define_memory_constraint "m" > + "An address that is not base reg + index reg or post modify." > + (and (match_code "mem") > + (and (match_test "memory_address_addr_space_p (GET_MODE (op), XEXP > (op, 0), > + MEM_ADDR_SPACE (op))") > + (not (match_test "((GET_CODE (XEXP (op, 0)) == PLUS > + && GET_CODE (XEXP (XEXP (op, 0), 0)) == REG > + && GET_CODE (XEXP (XEXP (op, 0), 1)) == REG) > + || GET_CODE (XEXP (op, 0)) == POST_MODIFY) > + && TARGET_XCVMEM"))))) > +
I would suggest not overriding `m` and using the same move pattern instead, like th_output_move. I believe that should be good for both code gen and maintainability. For codegen, IRA/LRA would like to see all possible solutions put within the move pattern. > (define_constraint "I" > "An I-type 12-bit signed immediate." > (and (match_code "const_int") > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h > index 1e9813b4f39..185e7d6ce23 100644 > --- a/gcc/config/riscv/riscv.h > +++ b/gcc/config/riscv/riscv.h > @@ -44,6 +44,8 @@ along with GCC; see the file COPYING3. If not see > #define RISCV_TUNE_STRING_DEFAULT "rocket" > #endif > > +#define TARGET_MEM_CONSTRAINT 'w' Maybe I missed something but I didn't see it used anywhere? > + > extern const char *riscv_expand_arch (int argc, const char **argv); > extern const char *riscv_expand_arch_from_cpu (int argc, const char **argv); > extern const char *riscv_default_mtune (int argc, const char **argv); > diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md > index 168c8665a7a..5c9ea62d943 100644 > --- a/gcc/config/riscv/riscv.md > +++ b/gcc/config/riscv/riscv.md > @@ -1663,13 +1663,13 @@ > > (define_expand "zero_extendsidi2" > [(set (match_operand:DI 0 "register_operand") > - (zero_extend:DI (match_operand:SI 1 "nonimmediate_operand")))] > + (zero_extend:DI (match_operand:SI 1 "nonimmediate_nonpostinc")))] Does Core-V support RV64? Does it xcvmem support cv.lwu if it supports RV64? Don't change this if it does not support RV64, and see comment of zero_extendhi if it supports. > "TARGET_64BIT") > > (define_insn_and_split "*zero_extendsidi2_internal" > [(set (match_operand:DI 0 "register_operand" "=r,r") > (zero_extend:DI > - (match_operand:SI 1 "nonimmediate_operand" " r,m")))] > + (match_operand:SI 1 "nonimmediate_nonpostinc" " r,m")))] > "TARGET_64BIT && !TARGET_ZBA && !TARGET_XTHEADBB && !TARGET_XTHEADMEMIDX > && !(register_operand (operands[1], SImode) > && reg_or_subregno (operands[1]) == VL_REGNUM)" > @@ -1691,13 +1691,13 @@ > (define_expand "zero_extendhi<GPR:mode>2" > [(set (match_operand:GPR 0 "register_operand") > (zero_extend:GPR > - (match_operand:HI 1 "nonimmediate_operand")))] > + (match_operand:HI 1 "nonimmediate_nonpostinc")))] I would like to prevent this change if possible. > "") > > (define_insn_and_split "*zero_extendhi<GPR:mode>2" > [(set (match_operand:GPR 0 "register_operand" "=r,r") > (zero_extend:GPR > - (match_operand:HI 1 "nonimmediate_operand" " r,m")))] > + (match_operand:HI 1 "nonimmediate_nonpostinc" " r,m")))] > "!TARGET_ZBB && !TARGET_XTHEADBB && !TARGET_XTHEADMEMIDX" > "@ > # Use riscv_output_move for outputting lhu, then it should be able to naturally support cv.lhu as well. Same comment for all other zero_extend* and extend* patterns. > @@ -1827,7 +1827,7 @@ > }) > > (define_insn "*movhf_hardfloat" > - [(set (match_operand:HF 0 "nonimmediate_operand" "=f, f,f,f,m,m,*f,*r, > *r,*r,*m") > + [(set (match_operand:HF 0 "nonimmediate_nonpostinc" "=f, > f,f,f,m,m,*f,*r, *r,*r,*m") Just repeat here, I really want to prevent using separated patterns to handle postinc. > (match_operand:HF 1 "move_operand" " > f,zfli,G,m,f,G,*r,*f,*G*r,*m,*r"))] > "TARGET_ZFHMIN > && (register_operand (operands[0], HFmode)
