From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x1036.google.com (mail-pj1-x1036.google.com [IPv6:2607:f8b0:4864:20::1036]) by sourceware.org (Postfix) with ESMTPS id 7BEB13858D28 for ; Fri, 17 Mar 2023 16:57:54 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7BEB13858D28 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-pj1-x1036.google.com with SMTP id f6-20020a17090ac28600b0023b9bf9eb63so5843594pjt.5 for ; Fri, 17 Mar 2023 09:57:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1679072273; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=Qk7OxLzM/1eRB6QS+xSblPi3lI2WU8h9jmchpSvME8Y=; b=BJjHVa4xLC9Jl0oYmd5+3tisFfLc7ayuIQqDovxTXSGt4Xv/5URXhE2fPgF5+5iZX+ 3Kgt5BlcjdMZOsq6Mv6K4My5i3FTTM0p8ZRGvyGG0lDLSdEgW3PY+JlH1FUPlZkehbI3 vvgc+9O1/U9aGqVuEJ0w2kOK9OW3TLsn6BbewqGL91BdM4lLKv5SwyL2Uq7C42gJH2NJ gUsimqFjP8rDFPjsUDSqanZ9+a6XccsQhoCeYTGC07oftjTxZokA2QlLVjIM7JwQVhTd AFTYGVSeh8dML21cT08rlh5Agvx6C75yEoRjEQuUgqeCCKbGroV9HD4Npe5XeoPPNb6F JhTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679072273; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qk7OxLzM/1eRB6QS+xSblPi3lI2WU8h9jmchpSvME8Y=; b=DBh9qjQMbVXyZEyMZTGzRb0PnBpr/KaYMImKUmp5K0PC7plBcri8YZ8l2EvQ566Gu2 KjyiKFm2n+V/8iR4Qv/dHBG2ftjRkwQ+5FbMX3GojkhXjckaGAnWCyXue5FOVx04epH5 MPFfeK1HY7nzVvZEQm6SrQrfl7qUNN7E34a8yfkVGRaUME73rJ59qsZuT5KdFAa8BCat NqcF0t0unYH7Vma4/05oHIhMeDw8KErGIkzBvqeU4CpKm/d9Te8KO9FCuigousERwGkt I3jvApeoktcsjSi3wE5MbTtUUWHOHg/1nmFTTMy/yZpHtk/3PZFRB/+9iMfDYXO2o4VU 3o2Q== X-Gm-Message-State: AO0yUKXUpzNoSsWKjJV4myT8Gh5zRg7rIiEnZh+pHkD4JjJWaIYQTM8k CZRe2ekl1nEoLUAlZNKaI+v5jA== X-Google-Smtp-Source: AK7set8hMmIPtWWrfKtxO7jzGjUbVwxd/gCrmxFKqMgdJfU6IbDz1OqMo7JjPksq2JxYZtPW5aDtdA== X-Received: by 2002:a17:902:e749:b0:1a0:45f6:d7ce with SMTP id p9-20020a170902e74900b001a045f6d7cemr8670366plf.32.1679072273363; Fri, 17 Mar 2023 09:57:53 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id jk1-20020a170903330100b001a1929e7985sm1803146plb.22.2023.03.17.09.57.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 09:57:52 -0700 (PDT) Date: Fri, 17 Mar 2023 09:57:52 -0700 (PDT) X-Google-Original-Date: Fri, 17 Mar 2023 09:57:48 PDT (-0700) Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant In-Reply-To: <01864d87-ce93-1e1b-926f-0a681a477ead@gmail.com> CC: Kito Cheng , collison@rivosinc.com, juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, richard.sandiford@arm.com, richard.guenther@gmail.com From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org, Vineet Gupta Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00,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: On Tue, 14 Mar 2023 10:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > > On 2/23/23 21:04, Kito Cheng wrote: >> Hi Jeff: >> >>> What I'd been planning to do internally at Ventana was to update our >>> codebase to gcc-13 once it's released. Then I'd backport RVV autovec >>> work from the gcc-14 dev tree into that Ventana branch. >>> >>> Instead, but along the same lines, we could have a public gcc-13 based >>> branch which follows that same process and where Rivos, SiFive, Rivai, >>> Ventana (and potentially others with an interest in this space) could >>> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd >>> probably have to hash out a bit of policy with the shared branch, but >>> I'd like to think we could make it work. >> >> +1, I like the idea, I could imagine we definitely will do the same >> work more than four times by different companies if we don't have a >> collaboration branch... > So it looks like there's a general sense that a coordination branch off > gcc-13 is reasonable. So I'd like to hammer out a few details. > > > First, I recommend we cut a branch from gcc-13 soon after gcc-13 > branches. That way we've got a place to land the vector work. > > Second, I recommend we rebase that branch periodically so that it > follows gcc-13. That means downstream consumers may have non-ff pulls, > but I think we want to follow gcc-13 fairly closely. I'm open to other > approaches here. > > Third, I was thinking that once a patch related to risc-v vectorization > goes to the trunk, any one of the principals should be able to > cherry-pick that patch onto our branch. I'm a little bit confused about what the proposal is here: is the idea to have a branch based on gcc-13 where we coordinate work before it lands on trunk, or a branch based on gcc-13 where we backport autovec-related patches once they've landed on trunk? In my mind those are actually two different things and I think they're both useful, maybe we should just do both? Having a shared work-in-progress branch for the autovec stuff makes sense to me: it's a big patch set with engineers at multiple companies working on it, so having a shared patch stack should help with the coordination. That branch will need to get re-written as patches get reviewed/merged, so having it rebase seems reasonable. I'd have the branch based on trunk, as that's the eventual target for the patches, but trunk can be unstable so maybe that'll be too much of a headache. For pretty much every other GCC release we've ended up with a "extra RISC-V backports" branch, where we end up with some patches that aren't suitable for proper upstream backports (usually because they're a performance improvement). We've always talked about doing that as a FSF vendor branch, but I don't think we really ever got organized enough to do it. We're doing that internally anyway at Rivos and I'd bet everyone else is too, it'd be great to find some way to share as much of that work as we can. It's sort of a headache to just propose doing everything, but in this case I think we're going to end up with various flavors of both of these branches internally at the various companies so we might as well just try and do that in public where we can. > That implies we need to identify the principals. I'll suggest Kito, > Juzhe, Michael and myself as the initial list. I'm certainly open to > others joining. +Vineet, who's been handling our internal GCC branches. We'll still have internal branches for 13 regardless of how the autovec stuff proceeds, but having any sort of upstream backport branch will make life easier as we'll be able to share some of that work. > Other thoughts or suggestions? Sorry if that throws a bit of a wrench in the works. Just for context: in Rivos land we don't have any specific timelines around 13, so the goal on our end is just to keep the vectorization stuff progressing smoothly as we spin up more engineering resources on it. Our aim is just to get everything on trunk eventually, anything else is just a stop-gap and we can work around it (though sharing that work is always a win). > > Jeff From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id 1A1AC385B523 for ; Fri, 17 Mar 2023 16:57:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1A1AC385B523 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-pl1-x635.google.com with SMTP id ja10so5940765plb.5 for ; Fri, 17 Mar 2023 09:57:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; t=1679072276; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:from:to:cc:subject:date:message-id :reply-to; bh=Qk7OxLzM/1eRB6QS+xSblPi3lI2WU8h9jmchpSvME8Y=; b=dApxA5quj1U27icQ87V0JnsWSeTXJcRPYI9RgncAFWGbGkFf3kJaYCTFWOfysq5cIT axkAqdgkLGWDNo94kmiu3fQw4DRritK/KWc+1nbMuHt46kK4UXN6x7apBFkpAqOeKF9q H5+nmtEWwyhqKgWe+Bd/IgYrY7NUDqvcKqNgRdNIEzSv54cBekv0h6VpfwebTI3E3/EP 6d9ipfWNmJaSohwmWj7VznNM7E80DD07YpAeecWew4MZac3CzHiJ8FnpHz5B8jFNKnH6 cZwQb6ZQP81WyaQ6fTLbZDLzr2BeHbMm83y4D4/Y+j9J1AOEflr+FPhHjfGK1GeuIC4U ZiXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1679072276; h=content-transfer-encoding:mime-version:message-id:to:from:cc :in-reply-to:subject:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Qk7OxLzM/1eRB6QS+xSblPi3lI2WU8h9jmchpSvME8Y=; b=y+ZHjYapCOwq/XCNK/weOdksE3aU9yYTX2i7moWVJcRdslmvIpSp8XNRT+I/K2avBt r0zR9PTGq7aDZ0xuSh3XzdPVsdKZgA6xIDOhoNSh7nCqsZp62YrrO5Cwp1vM8p3FFr39 wkbyTJWYJrO3REEOfoFVRqEUx1iDLdMEmqCB5iTk17MnSpRR0hjqYU7R0/0zOG+rDEET cetMr8sPc67P+IvaSX4ZmEcp1bFzsmSfZS3rDnkcV/0pvZyH1+bFZKb0g7BUN3Z2KR9N 18lNYh32NQTDXtGYTYTZYC9fXKtQ2d3NQx5gYLpiKYwpCGxz0qE5gGYZS64s2rvkGvRi eGyw== X-Gm-Message-State: AO0yUKVadjyCxGcbC6MCVX/11Gu8tNe64eMXpI+Xiq0WjH72TN70dpnA oZ6KOKGrAKprm00F26OsV3ZWzw== X-Google-Smtp-Source: AK7set9hRJREac5F41TWhPBCdfoa2nk0o0nNVlCEnL8XPtYJNKjqne6mnD/57HARHOWh1wg+xK631A== X-Received: by 2002:a17:902:ea05:b0:19f:27fd:7cb5 with SMTP id s5-20020a170902ea0500b0019f27fd7cb5mr8971470plg.10.1679072276055; Fri, 17 Mar 2023 09:57:56 -0700 (PDT) Received: from localhost ([135.180.227.0]) by smtp.gmail.com with ESMTPSA id jm5-20020a17090304c500b0019ccded6a46sm1769691plb.228.2023.03.17.09.57.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 17 Mar 2023 09:57:55 -0700 (PDT) Date: Fri, 17 Mar 2023 09:57:55 -0700 (PDT) X-Google-Original-Date: Fri, 17 Mar 2023 09:57:48 PDT (-0700) Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant In-Reply-To: <01864d87-ce93-1e1b-926f-0a681a477ead@gmail.com> CC: Kito Cheng , collison@rivosinc.com, juzhe.zhong@rivai.ai, gcc-patches@gcc.gnu.org, kito.cheng@sifive.com, richard.sandiford@arm.com, richard.guenther@gmail.com From: Palmer Dabbelt To: gcc-patches@gcc.gnu.org, Vineet Gupta Message-ID: Mime-Version: 1.0 (MHng) Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,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: <20230317165755.2WtS8ATuByP4ZgJL7_Mj98641KlC-0vwdd0oHGTt_78@z> On Tue, 14 Mar 2023 10:48:24 PDT (-0700), gcc-patches@gcc.gnu.org wrote: > > > On 2/23/23 21:04, Kito Cheng wrote: >> Hi Jeff: >> >>> What I'd been planning to do internally at Ventana was to update our >>> codebase to gcc-13 once it's released. Then I'd backport RVV autovec >>> work from the gcc-14 dev tree into that Ventana branch. >>> >>> Instead, but along the same lines, we could have a public gcc-13 based >>> branch which follows that same process and where Rivos, SiFive, Rivai, >>> Ventana (and potentially others with an interest in this space) could >>> collaborate. Essentially it'd be gcc-13 + RVV autovec support. We'd >>> probably have to hash out a bit of policy with the shared branch, but >>> I'd like to think we could make it work. >> >> +1, I like the idea, I could imagine we definitely will do the same >> work more than four times by different companies if we don't have a >> collaboration branch... > So it looks like there's a general sense that a coordination branch off > gcc-13 is reasonable. So I'd like to hammer out a few details. > > > First, I recommend we cut a branch from gcc-13 soon after gcc-13 > branches. That way we've got a place to land the vector work. > > Second, I recommend we rebase that branch periodically so that it > follows gcc-13. That means downstream consumers may have non-ff pulls, > but I think we want to follow gcc-13 fairly closely. I'm open to other > approaches here. > > Third, I was thinking that once a patch related to risc-v vectorization > goes to the trunk, any one of the principals should be able to > cherry-pick that patch onto our branch. I'm a little bit confused about what the proposal is here: is the idea to have a branch based on gcc-13 where we coordinate work before it lands on trunk, or a branch based on gcc-13 where we backport autovec-related patches once they've landed on trunk? In my mind those are actually two different things and I think they're both useful, maybe we should just do both? Having a shared work-in-progress branch for the autovec stuff makes sense to me: it's a big patch set with engineers at multiple companies working on it, so having a shared patch stack should help with the coordination. That branch will need to get re-written as patches get reviewed/merged, so having it rebase seems reasonable. I'd have the branch based on trunk, as that's the eventual target for the patches, but trunk can be unstable so maybe that'll be too much of a headache. For pretty much every other GCC release we've ended up with a "extra RISC-V backports" branch, where we end up with some patches that aren't suitable for proper upstream backports (usually because they're a performance improvement). We've always talked about doing that as a FSF vendor branch, but I don't think we really ever got organized enough to do it. We're doing that internally anyway at Rivos and I'd bet everyone else is too, it'd be great to find some way to share as much of that work as we can. It's sort of a headache to just propose doing everything, but in this case I think we're going to end up with various flavors of both of these branches internally at the various companies so we might as well just try and do that in public where we can. > That implies we need to identify the principals. I'll suggest Kito, > Juzhe, Michael and myself as the initial list. I'm certainly open to > others joining. +Vineet, who's been handling our internal GCC branches. We'll still have internal branches for 13 regardless of how the autovec stuff proceeds, but having any sort of upstream backport branch will make life easier as we'll be able to share some of that work. > Other thoughts or suggestions? Sorry if that throws a bit of a wrench in the works. Just for context: in Rivos land we don't have any specific timelines around 13, so the goal on our end is just to keep the vectorization stuff progressing smoothly as we spin up more engineering resources on it. Our aim is just to get everything on trunk eventually, anything else is just a stop-gap and we can work around it (though sharing that work is always a win). > > Jeff