From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x34.google.com (mail-oa1-x34.google.com [IPv6:2001:4860:4864:20::34]) by sourceware.org (Postfix) with ESMTPS id 0EFA53858CD1 for ; Wed, 20 Dec 2023 22:12:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0EFA53858CD1 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0EFA53858CD1 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:4860:4864:20::34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703110322; cv=none; b=qntwTKRUbVb5MiSRRzJ7CVMX8IYFPpSEDlhIwY5f/0Jfud3tnapF4cFfPzJ6oMT5fMtBga+94teFIny2uYYC5AV2uuHAFawar4ZetAq+FMtxPbXnka3tLx1Z8lRIEWD3IEjaac6jXPU8qET3G+cI0IWUXqAoPCsxumDSmGYsRlg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703110322; c=relaxed/simple; bh=VcoHG47ErY3fp7u0wcKUaqez6Lv/PiT3KHiklTb/XRs=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=mYtZpzOIoPP2G3oZppq13bq7riPpzKY6PVAoQTvNCmhQmvmIkXABO2iw4d6mzFzXG09A2saTBnkpwBE6KFjW3icwOukJ2SzyaEqUxGnmnAHZdU8WeeB1RCHewpGhjODJmqfRr79G30T4UbwlbZ6qQh2E1pEtrmHuWJoMDubViwY= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-oa1-x34.google.com with SMTP id 586e51a60fabf-20400d5b54eso49360fac.1 for ; Wed, 20 Dec 2023 14:12:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1703110319; x=1703715119; darn=gcc.gnu.org; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:cc :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=nmfyjNdejvihD6J/NNgw4Y+FXQmj+kCZIXBVWE5hf+Y=; b=JFGD9e3ydJloiGJB+O8Oo/kwY3uuqKEjrshU04AuCNebRV/KXNZmQfgvifvBn8lB7q XXXy1P31EMIRW511RnLOQzBSwf2Jh7RDY2ubdRkPz8Foxigs7KVcr+5EZAI9tL6OQQ+P Syr6h27v2doR1kBX1G0VkYi2bAd/LlwRFY9/xiwABonSN5b/3XE/gUlqbwx16Fr8vgJ2 1actOgwEn2DsTioMuqAH48JkdaFxdOGaRMdoq6+VgSVWT91vRORFMOyoCwHv+bwb1NLb 99JHmuUSuZSAOT8LV/8xbHVQGvqKCoDFXGleYUR3l01J+cmjMEvUNGUQxBkgCfyUY1Xm xZKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1703110319; x=1703715119; h=content-transfer-encoding:in-reply-to:from:references:newsgroups:cc :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=nmfyjNdejvihD6J/NNgw4Y+FXQmj+kCZIXBVWE5hf+Y=; b=TYHCxNNXHUnLgr8AkmkbxMGvmS+WhbWe6VmaFJMwSKMx1cYR0NKdIzuDeozCQ13Ixd 1fVCdZFIM8jRL7O33FbWOdVVP8+cYL37WQvJSNyuhtV8EPEifGFlFhuYujr6gAHDDYXI 2AIGWz4OuYQhO9LeFjFAogdkzwnWX6D+fQbKSM8OmZff9wIPu/j0XRCLbdzwgth0Eufr 0/xZ7ochx/DkBOpcPtnoANYz1nRTVfBHMGpWILMYxR5bFhEsCLT15e6wHt730+v0FKqZ qt4wCrqbAcqigdjUx5W9hw5MZA0VaTXpVSDpo5MN9I2rVpK5RVWbSwsWKON9YZTYlOVv J5Mw== X-Gm-Message-State: AOJu0YxEdQdC9dnyJORTQ8h4bTF3/5NnL1r8/06k/WrVC3nUG7Ziq1tv rRxDKoW4mcquT24CZWoyGXZvCg== X-Google-Smtp-Source: AGHT+IG1PnkFP2mg7msrpfduijD69ZcFMtMkTsK2G3L/hZgoHXsgfmW7CtxgxGtE2hV1brFlj/Ca2A== X-Received: by 2002:a05:6870:1585:b0:203:c92c:72d5 with SMTP id j5-20020a056870158500b00203c92c72d5mr525915oab.32.1703110319332; Wed, 20 Dec 2023 14:11:59 -0800 (PST) Received: from [10.0.17.83] ([12.44.203.122]) by smtp.gmail.com with ESMTPSA id g7-20020a056870ea0700b0020328263f6fsm129528oap.25.2023.12.20.14.11.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 20 Dec 2023 14:11:59 -0800 (PST) Message-ID: <9a30c4b3-3b78-41f4-8e72-994275d68e26@rivosinc.com> Date: Wed, 20 Dec 2023 14:11:57 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines Content-Language: en-US To: Jeff Law , gcc-patches@gcc.gnu.org Cc: gnu-toolchain@rivosinc.com, kito.cheng@gmail.com Newsgroups: gmane.comp.gcc.patches References: <20231215185328.794425-1-ewlu@rivosinc.com> <20231215185328.794425-2-ewlu@rivosinc.com> <819cc2ca-38ef-49dc-9d1e-e5af60ccd66b@gmail.com> From: Edwin Lu In-Reply-To: <819cc2ca-38ef-49dc-9d1e-e5af60ccd66b@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-10.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,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: On 12/20/2023 10:50 AM, Jeff Law wrote: > > > On 12/15/23 11:53, Edwin Lu wrote: >> This patch does not create vector related insn reservations for >> generic.md and sifive-7.md. It updates/creates insn reservations >> for all non-vector typed insns >> >> gcc/ChangeLog: >> >>     * config/riscv/generic-ooo.md (generic_ooo_sfb_alu): create/update >> reservation >>     (generic_ooo_branch): ditto >>     * config/riscv/generic.md (generic_sfb_alu): ditto >>     * config/riscv/sifive-7.md (sifive_7_popcount): ditto >> >> Signed-off-by: Edwin Lu >> --- >>   gcc/config/riscv/generic-ooo.md | 16 +++++++++++++--- >>   gcc/config/riscv/generic.md     | 13 +++++++++---- >>   gcc/config/riscv/sifive-7.md    | 12 +++++++++--- >>   3 files changed, 31 insertions(+), 10 deletions(-) >> >> diff --git a/gcc/config/riscv/generic-ooo.md >> b/gcc/config/riscv/generic-ooo.md >> index 78b9e48f935..de93245f965 100644 >> --- a/gcc/config/riscv/generic-ooo.md >> +++ b/gcc/config/riscv/generic-ooo.md >> @@ -95,7 +95,7 @@ (define_insn_reservation "generic_ooo_float_store" 6 >>   ;; Vector load/store >>   (define_insn_reservation "generic_ooo_vec_load" 6 >>     (and (eq_attr "tune" "generic_ooo") >> -       (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr")) >> +       (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr,rdfrm")) >>     "generic_ooo_vxu_issue,generic_ooo_vxu_alu") > Hmm, I don't think "rdfrm" is really a vector load.  It's really a read > of some bits in the fpcsr which elsewhere is handled as type fmove.  I'd > actually suggest fixing vector.md to use fmove on the appropriate insn, > then dropping rdfrm entirely. > Sounds good! > > >>   (define_insn_reservation "generic_xfer" 3 >>     (and (eq_attr "tune" "generic") >> -       (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp")) >> +       (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp,cbo")) >>     "alu") > cbo is probably closer to a load/store than it is a transfer operation. > That makes sense. I wasn't sure where exactly to put it since we have two separate insn reservations for load and store and from my understanding, the same type cannot be in two separate insn reservations. Would a new insn reservation like (define_insn_reservation "generic_load_store" 2 ...) work? >>   (define_insn_reservation "generic_branch" 1 >>     (and (eq_attr "tune" "generic") >> -       (eq_attr "type" "branch,jump,call,jalr")) >> +       (eq_attr "type" "branch,jump,call,jalr,ret,trap,pushpop")) >> +  "alu") > pushpop are a mix of some pure memory operations and some mixed memory + > branch. > > However, from a scheduling standpoint the branch isn't particularly > interesting.  So I'd have pushpop as a load/store. > Same as above Edwin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) by sourceware.org (Postfix) with ESMTPS id 06301386182D for ; Wed, 20 Dec 2023 22:12:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06301386182D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=m.gmane-mx.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 06301386182D Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=116.202.254.214 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703110334; cv=none; b=P7hmi5c7M+MXisQ42CiVM65R9YMV8XQxP4WESjyAzhBi/Xg3e4PF3Xecy9KHtdmauPp4Lml7RkaK4zNyTRavadsQCFD4py5QqCyNQSOqTEyXdqrPoOi7aIrLbWMnBLZXEE9eJmDpC6b4p/vh3pGkoJ6od8GFpJ4/Ino1xYFRImo= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1703110334; c=relaxed/simple; bh=VcoHG47ErY3fp7u0wcKUaqez6Lv/PiT3KHiklTb/XRs=; h=To:From:Subject:Date:Message-ID:Mime-Version; b=uIjjeABoVkfxK+tTmxKGnPyxaOkffFsWLarY2jGjSXCvt4UV6NidPke5Uit6PV7nk+epsFjlr8F1FtIVCZhJeRE6pnNUApMrYewkXGCNMQLGlsRMeynr6exZr4g5UKtPHBXDbgb4mP1ZxFgTapxD5QUq4m8pXN6fqnh8mi+ZwNk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1rG4nT-00074k-1O for gcc-patches@gcc.gnu.org; Wed, 20 Dec 2023 23:12:11 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Edwin Lu Subject: Re: [PATCH 1/3][RFC] RISC-V: Add non-vector types to pipelines Date: Wed, 20 Dec 2023 14:11:57 -0800 Message-ID: <9a30c4b3-3b78-41f4-8e72-994275d68e26@rivosinc.com> References: <20231215185328.794425-1-ewlu@rivosinc.com> <20231215185328.794425-2-ewlu@rivosinc.com> <819cc2ca-38ef-49dc-9d1e-e5af60ccd66b@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla Thunderbird Cc: gnu-toolchain@rivosinc.com, kito.cheng@gmail.com Content-Language: en-US In-Reply-To: <819cc2ca-38ef-49dc-9d1e-e5af60ccd66b@gmail.com> X-Spam-Status: No, score=-8.0 required=5.0 tests=BAYES_00,BODY_8BITS,GIT_PATCH_0,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Message-ID: <20231220221157.uEF5euC2NSUHEEH3Dr2lMQwlYX60Nitu2BZlLwULmpI@z> On 12/20/2023 10:50 AM, Jeff Law wrote: > > > On 12/15/23 11:53, Edwin Lu wrote: >> This patch does not create vector related insn reservations for >> generic.md and sifive-7.md. It updates/creates insn reservations >> for all non-vector typed insns >> >> gcc/ChangeLog: >> >>     * config/riscv/generic-ooo.md (generic_ooo_sfb_alu): create/update >> reservation >>     (generic_ooo_branch): ditto >>     * config/riscv/generic.md (generic_sfb_alu): ditto >>     * config/riscv/sifive-7.md (sifive_7_popcount): ditto >> >> Signed-off-by: Edwin Lu >> --- >>   gcc/config/riscv/generic-ooo.md | 16 +++++++++++++--- >>   gcc/config/riscv/generic.md     | 13 +++++++++---- >>   gcc/config/riscv/sifive-7.md    | 12 +++++++++--- >>   3 files changed, 31 insertions(+), 10 deletions(-) >> >> diff --git a/gcc/config/riscv/generic-ooo.md >> b/gcc/config/riscv/generic-ooo.md >> index 78b9e48f935..de93245f965 100644 >> --- a/gcc/config/riscv/generic-ooo.md >> +++ b/gcc/config/riscv/generic-ooo.md >> @@ -95,7 +95,7 @@ (define_insn_reservation "generic_ooo_float_store" 6 >>   ;; Vector load/store >>   (define_insn_reservation "generic_ooo_vec_load" 6 >>     (and (eq_attr "tune" "generic_ooo") >> -       (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr")) >> +       (eq_attr "type" "vlde,vldm,vlds,vldux,vldox,vldff,vldr,rdfrm")) >>     "generic_ooo_vxu_issue,generic_ooo_vxu_alu") > Hmm, I don't think "rdfrm" is really a vector load.  It's really a read > of some bits in the fpcsr which elsewhere is handled as type fmove.  I'd > actually suggest fixing vector.md to use fmove on the appropriate insn, > then dropping rdfrm entirely. > Sounds good! > > >>   (define_insn_reservation "generic_xfer" 3 >>     (and (eq_attr "tune" "generic") >> -       (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp")) >> +       (eq_attr "type" "mfc,mtc,fcvt,fmove,fcmp,cbo")) >>     "alu") > cbo is probably closer to a load/store than it is a transfer operation. > That makes sense. I wasn't sure where exactly to put it since we have two separate insn reservations for load and store and from my understanding, the same type cannot be in two separate insn reservations. Would a new insn reservation like (define_insn_reservation "generic_load_store" 2 ...) work? >>   (define_insn_reservation "generic_branch" 1 >>     (and (eq_attr "tune" "generic") >> -       (eq_attr "type" "branch,jump,call,jalr")) >> +       (eq_attr "type" "branch,jump,call,jalr,ret,trap,pushpop")) >> +  "alu") > pushpop are a mix of some pure memory operations and some mixed memory + > branch. > > However, from a scheduling standpoint the branch isn't particularly > interesting.  So I'd have pushpop as a load/store. > Same as above Edwin