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 018703858D35 for ; Tue, 10 Oct 2023 21:18:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 018703858D35 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 Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1qqK7s-0002Qg-5p for gcc-patches@gcc.gnu.org; Tue, 10 Oct 2023 23:18:48 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gcc-patches@gcc.gnu.org From: Edwin Lu Subject: Re: [RFC] RISC-V: Handle new types in scheduling descriptions Date: Tue, 10 Oct 2023 14:18:40 -0700 Message-ID: References: <20231009210250.947831-1-ewlu@rivosinc.com> <101c89cb-df98-4e12-be41-5c20870b6d7d@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 Content-Language: en-US In-Reply-To: <101c89cb-df98-4e12-be41-5c20870b6d7d@gmail.com> X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,BODY_8BITS,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no 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 10/10/2023 10:11 AM, Jeff Law wrote: > > > On 10/9/23 15:02, Edwin Lu wrote: >> Now that every insn is guaranteed a type, we want to ensure the types are >> handled by the existing scheduling descriptions. >> >> There are 2 approaches I see: >> 1. Create a new pipeline intended to eventually abort (sifive-7.md) >> 2. Add the types to an existing pipeline (generic.md) >> >> Which approach do we want to go with? If there is a different approach we >> want to take instead, please let me know as well. >> >> Additionally, should types associated with specific extensions >> (vector, crypto, etc) have specific pipelines dedicated to them? >> >>     * config/riscv/generic.md: update pipeline >>     * config/riscv/sifive-7.md (sifive_7): update pipeline >>     (sifive_7_other): > I'd largely expect that we look at an unhandled type and first look to > see if its properties roughly fit into an existing define_insn_unit.  If > so, just add it to the existing unit.  Otherwise we end up needing to > create another unit. > The main types that were added that are not associated with any extension would be "trap" type and the "cbo" (cache block operation) type. I have added these types to an existing pipeline in the generic.md file. For the vector extension, I don't believe the existing pipelines would support those operations. Should I create the pipelines for now? > What would be really interesting would be to see if we can get the > scheduler to indicate that it's trying to schedule an insn that doesn't > have a reservation.    ie, our backend tells us if we have an insn with > no type, the next step is to see if we have a type with no > units/reservations. > > > Jeff > Do you happen to have any idea on how to do this or if there are any existing mechanisms I should look at? I have been searching around the docs to see if there was any way to tell which pipeline (if any) an instruction is using when it is not included under a reservation without any luck. Edwin From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) by sourceware.org (Postfix) with ESMTPS id D24D13858D28 for ; Tue, 10 Oct 2023 21:18:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D24D13858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com Received: by mail-ot1-x332.google.com with SMTP id 46e09a7af769-6c4b9e09521so4116493a34.3 for ; Tue, 10 Oct 2023 14:18:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1696972723; x=1697577523; 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=j4NpHN/IN0GMgTBgBcskeVTzkU7WZxQkacduJcH9XhA=; b=cOmPPOta70tBCQsKTGzP2HQAt4Qb47kDroUcHElB8XjZkB5PV923frwGiqFMXIOXTq wEdxT+P9cfoRPiCF12lai9CdwrsL+H7TOdDcSKk7LoFuyNlV+H1rfEaf/p7bvxCCX4EY XPuQs0CRI4zoqWWiMd6VS61gk7x5MluC5AByjvfoHzYVtKDfpqNdgt0iP55jxOA5S4PD v0n0FBe0h+yo8cHeqiV8rDxH5cAWyBp4f37002lGyqDdZg5acp2O16c/v1/TH+MPRTUO xgvPB8SNCv5sHy0sfA+DBv9TiLjQUByojetaHsUqod+CvakypqVyJu1Xy0lHnzNqXkxz HT+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1696972723; x=1697577523; 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=j4NpHN/IN0GMgTBgBcskeVTzkU7WZxQkacduJcH9XhA=; b=TQ7mk4cciNjCIVgLCn+nhPwLjAU/JSnS3zfWjZq2vKOgqJnF1GmuiaKS3SMyQikxXr lhRys1rk9/dDrfFsj9a3jCxPXRzSWsGOHws25grPDEzxLXgnGozZy4FI51txfoAEx7sr EC2ox4Z7dwu3coIc3q9tTMveWN1hT8rDOSjy7Oy3y4CTctCjS1pR0zg6tGsZaEsjUMw0 Kf7BtKM7lfVGBVpunLspVyZAQfhDsX7qaey7UptU6U8XrA526v29SqkW45SHyfSwwPwP L5FRQ4jLUdskaXrqaOpxq3n1EfMrV/F8hXK4bg1QENn+4nXR6dI0U8aSe9JtVcSNolAN NOAg== X-Gm-Message-State: AOJu0Yw36JagiDZ5YHfQvqqyCg8slqnaC/6+ff046SpsDMN4zP03EGLD 4arHlqgbWIuHyVpqgMCgvrGh4ochnLFy7dgVuME= X-Google-Smtp-Source: AGHT+IHIUnr5F+etMxg6GqYrhMLqu93Kop9YzzUZijFR9NUs/TM8zePwDQBaLEe9zphqInU+oriq1w== X-Received: by 2002:a05:6830:140b:b0:6bc:b2a2:7b02 with SMTP id v11-20020a056830140b00b006bcb2a27b02mr19412358otp.7.1696972722945; Tue, 10 Oct 2023 14:18:42 -0700 (PDT) Received: from [192.168.1.69] (107-218-158-12.lightspeed.sntcca.sbcglobal.net. [107.218.158.12]) by smtp.gmail.com with ESMTPSA id n22-20020a0568301e9600b006c65f431799sm1931603otr.23.2023.10.10.14.18.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 10 Oct 2023 14:18:42 -0700 (PDT) Message-ID: Date: Tue, 10 Oct 2023 14:18:40 -0700 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] RISC-V: Handle new types in scheduling descriptions Content-Language: en-US To: Jeff Law , gcc-patches@gcc.gnu.org Cc: gnu-toolchain@rivosinc.com Newsgroups: gmane.comp.gcc.patches References: <20231009210250.947831-1-ewlu@rivosinc.com> <101c89cb-df98-4e12-be41-5c20870b6d7d@gmail.com> From: Edwin Lu In-Reply-To: <101c89cb-df98-4e12-be41-5c20870b6d7d@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP 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: Message-ID: <20231010211840.MrrNuhrwNGpz-EI42oiSywTvSvZv0VNzF4pjsXUA_Bs@z> On 10/10/2023 10:11 AM, Jeff Law wrote: > > > On 10/9/23 15:02, Edwin Lu wrote: >> Now that every insn is guaranteed a type, we want to ensure the types are >> handled by the existing scheduling descriptions. >> >> There are 2 approaches I see: >> 1. Create a new pipeline intended to eventually abort (sifive-7.md) >> 2. Add the types to an existing pipeline (generic.md) >> >> Which approach do we want to go with? If there is a different approach we >> want to take instead, please let me know as well. >> >> Additionally, should types associated with specific extensions >> (vector, crypto, etc) have specific pipelines dedicated to them? >> >>     * config/riscv/generic.md: update pipeline >>     * config/riscv/sifive-7.md (sifive_7): update pipeline >>     (sifive_7_other): > I'd largely expect that we look at an unhandled type and first look to > see if its properties roughly fit into an existing define_insn_unit.  If > so, just add it to the existing unit.  Otherwise we end up needing to > create another unit. > The main types that were added that are not associated with any extension would be "trap" type and the "cbo" (cache block operation) type. I have added these types to an existing pipeline in the generic.md file. For the vector extension, I don't believe the existing pipelines would support those operations. Should I create the pipelines for now? > What would be really interesting would be to see if we can get the > scheduler to indicate that it's trying to schedule an insn that doesn't > have a reservation.    ie, our backend tells us if we have an insn with > no type, the next step is to see if we have a type with no > units/reservations. > > > Jeff > Do you happen to have any idea on how to do this or if there are any existing mechanisms I should look at? I have been searching around the docs to see if there was any way to tell which pipeline (if any) an instruction is using when it is not included under a reservation without any luck. Edwin