From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x633.google.com (mail-ej1-x633.google.com [IPv6:2a00:1450:4864:20::633]) by sourceware.org (Postfix) with ESMTPS id 64B493858C53 for ; Sun, 19 Nov 2023 07:55:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 64B493858C53 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 64B493858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::633 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700380548; cv=none; b=mtifzhVPj2VQyxqx/RlojrzdWoQ7rVrvrc4LdjQ+ZkAKxNRv1pCH1KDQ/hbJyDpRIB3fWGVYxDHVDk+WSIxIHP2GEU4wL6G+5KHAeRFwohndOe1evE960TjYllPGnN3o+su/UrZtHdT8EbhBHHkTQ/9OdTL/KLZOZKfbYNAulAA= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1700380548; c=relaxed/simple; bh=PUP0158scKeB/3eksPS38wwe4d7elMNLehGEDi5a/hY=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=vJuQ5LkmbM0ModlzP0sYUgj2vRbE+HjAbmcGW/T2WmjSxYlighQcFtjFvQebbn8S0ZPSmMnAh4UIXlqYNacdfdmciXlvMBe77WoT7gABLLykpNZTc3W4qDU/8ZGBe2D15VTGjO2k2ScS8mPpJ8tcHJ4TSdoMLinPokDhyHikyI4= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-ej1-x633.google.com with SMTP id a640c23a62f3a-9df8d0c2505so641273566b.0 for ; Sat, 18 Nov 2023 23:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1700380545; x=1700985345; darn=gcc.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=zSyCRiEdaz9TU+bISTfGIc7oGSh9/81xcao/3rmQfWM=; b=eBi7w4a+5EokFf0VIPsnjiHpcg4cstbknJwsY7mO1vkU84dLRQM9yjFqNp4+1/RhXR jiyvFxF2dVGG8kLqhKRwqbZGZxVrLJJzZ+C91WZhYASu+1ZptrSyNpsRasxPSUAiSqgT /2De12+dnJdWNXasQtHxPRiBOxoeYb2Sbswm2W/JSgy2vBWarFwW/+dFIydzHs9D6RFr BiYmNkOgqAK0UXxkG3KlfJwf/Sl18N4x0rEElZ0K/bfrGHygWgopFft6sPgL16w+OlX0 vHl6i42yLEAY9qq0/lZSd94EBokE9dsZV5YeUbOWoWUmtYEHHWkwT/u9eHsf2pU2Fx71 6Dkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700380545; x=1700985345; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=zSyCRiEdaz9TU+bISTfGIc7oGSh9/81xcao/3rmQfWM=; b=LEmxsHoWuUFYlid4vGG+9qodd7MLZFWMhL6edBPlI2Jiljz8+sJjZ2L7SCpANRF+i/ IgJyCgkVZ5uGeX71Bs//MxX5SdJonNa+JBka/6ZTeQycf1o3+Fzue+ZU9V5/sYTgS4ki sn4i/jjMYliOTBFLX/ww8Ggd6rQ2r+6OmbkBY+XDuYTvQhc+I1BCWMBut+VhiPJPhPac /lX6hTsJ9Md9n1VV8/8n2cUeiMHeGopIvkqVqLrQBZt5RujefHYP/vyhqJB+ZfAF7aZd dUwk4pQ/DD/AyXr3sve2DxQ83nRxagq+sxIVS7jTDqy8MUjbhowMzmgI5Rr4GdbzX5jq fqoQ== X-Gm-Message-State: AOJu0YxLSpbRVngidw4MT/3Bgtfgwcq0Ink00c6T6S5J1IV8phBQC3VZ 3b+kyDTRh4sB8KKjQiPA94/5Ikyvlmx49LzBQ6Uvo8TyLysreg== X-Google-Smtp-Source: AGHT+IGioEYJp9h7RTj9kipKkYrS19NHFjOiHiiLiquKkMRCA6q9S74ulQnLT8vLZcVYYtvusjp6SshSHVW8E+n3Zu0= X-Received: by 2002:a17:906:7387:b0:9fa:5594:4e94 with SMTP id f7-20020a170906738700b009fa55944e94mr3791750ejl.27.1700380544815; Sat, 18 Nov 2023 23:55:44 -0800 (PST) MIME-Version: 1.0 References: <20231109124219.966619-1-mary.bennett@embecosm.com> <20231109124219.966619-2-mary.bennett@embecosm.com> In-Reply-To: <20231109124219.966619-2-mary.bennett@embecosm.com> From: Kito Cheng Date: Sun, 19 Nov 2023 15:55:32 +0800 Message-ID: Subject: Re: [PATCH 1/1] RISC-V: Add support for XCVmem extension in CV32E40P To: Mary Bennett Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-8.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > 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_extendhi2" > [(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_extendhi2" > [(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)