From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x630.google.com (mail-pl1-x630.google.com [IPv6:2607:f8b0:4864:20::630]) by sourceware.org (Postfix) with ESMTPS id 326E8385842B for ; Fri, 24 Feb 2023 03:34:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 326E8385842B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-x630.google.com with SMTP id ko13so16014779plb.13 for ; Thu, 23 Feb 2023 19:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YgtUCL2kTR2M+HOQ7ibBp62VLlyBU/wjgPV4zjylTzU=; b=Gks8YhQLrEBwhYa3UTEjqqtxc1i02BwyJCmouJUdQfxAaplGPZp2u9JlCgtmmd9wTY 5eonR6YGVor0q9vx8iww/FOV8HJpmAiu8pfqfm3qIhVcRmSiXILmOGjLGOB28EPH6L5s VJPynb70TxTTf7C2uJZSXbONcgHsldi2DpKBfp7U71/dgi5BPgZ1q9Uvwvqd0dbM6NkR REDhp4S/BGg/hp2e1CmTL+FwPQ6VOxX+2VwzhxoDBchUBdbJzQK2gGgADqUNGnqIVYo4 DFjwGWrUjZaHD/dsFhzHHEb9FpdOaqHkSVMyOi7u3l+i04aX1cv0pg6m8Je0eF44OTyh HFKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references: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=YgtUCL2kTR2M+HOQ7ibBp62VLlyBU/wjgPV4zjylTzU=; b=eOqxtnVbcLD31i9Sg1xCPt1oaJ5LfiIuP2okjJV65jn4aqkoBVEw0o6JXreH9EAzMu It2pF2tjxzh9NYklgx3e1DOzd6QKKxMEl0QLCRTdmSE12u7VXVGFRarnogJLKqhFgXp1 yVUKnIPpnvA81VDTjbrZNRcW9CdTpDSIRBvua6b12V3VChkLEqCIjMmm5U3ytXlUqf/J ynrYqdURXcLVyRAB9agRDSCmaFxDV+yLSU6jRMRQsD4CGs8I2A37foUkTlboumEQwcS4 UTFNWHmC2n/fHNjRqt5fgKTkMY57exqjpkNrjG8cZTkRm3GRXRyoBkps349QkO+7MnmZ E/xw== X-Gm-Message-State: AO0yUKWO2RUy+arPW1ccMhzLH31Y3hoDsRKm1x7OYaCav26zPVWA9htD 1c4mV3LS+nvaAWjnGBZ5gIc= X-Google-Smtp-Source: AK7set9nTiHN/xM9+rb0k1iN+zH54GSW8/trPOFKs975blqYmW49EpqniQ64VWt+A1tR2FQqwzzg4Q== X-Received: by 2002:a17:90b:350f:b0:22c:8686:5f04 with SMTP id ls15-20020a17090b350f00b0022c86865f04mr15495615pjb.15.1677209695819; Thu, 23 Feb 2023 19:34:55 -0800 (PST) Received: from ?IPV6:2601:681:8600:13d0::f0a? ([2601:681:8600:13d0::f0a]) by smtp.gmail.com with ESMTPSA id ci14-20020a17090afc8e00b00233790759cesm426425pjb.47.2023.02.23.19.34.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 23 Feb 2023 19:34:55 -0800 (PST) Message-ID: Date: Thu, 23 Feb 2023 20:34:53 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.1 Subject: Re: [PATCH] vect: Check that vector factor is a compile-time constant Content-Language: en-US To: Michael Collison , juzhe.zhong@rivai.ai, gcc-patches Cc: "kito.cheng" , "kito.cheng" , "richard.sandiford" , "richard.guenther" References: <69622113-9b9f-f93d-b89d-0783b95bbfcb@gmail.com> <71276340-3acc-c700-d7b5-3f388442295b@rivosinc.com> From: Jeff Law In-Reply-To: <71276340-3acc-c700-d7b5-3f388442295b@rivosinc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,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 2/22/23 21:50, Michael Collison wrote: > Hi Jeff, > > We do not have two independent implementations: my work is 100% based on > the vector intrinsic foundation in upstream GCC. Phew! That's good news. I totally misunderstood. > In fact I have only > added two core patterns, vector add and subtract, that are based on the > existing vector intrinsics implementation: > > (define_expand "add3" >   [(match_operand:VI 0 "register_operand") >    (match_operand:VI 1 "register_operand") >    (match_operand:VI 2 "vector_arith_operand")] >   "TARGET_VECTOR" > { >   using namespace riscv_vector; > >   rtx merge = gen_rtx_UNSPEC (mode, gen_rtvec (1, const0_rtx), > UNSPEC_VUNDEF); >   rtx vl = emit_vlmax_vsetvl (mode); >   rtx mask_policy = get_mask_policy_no_pred(); >   rtx tail_policy = get_tail_policy_no_pred(); >   rtx mask = CONSTM1_RTX(mode); >   rtx vlmax_avl_p = get_avl_type_rtx(NONVLMAX); > >   emit_insn(gen_pred_add(operands[0], mask, merge, operands[1], > operands[2], >                 vl, tail_policy, mask_policy, vlmax_avl_p)); > >   DONE; > }) > > This pattern leverages the existing vector intrinsics framework. The > bulk of the changes are the cost model, and target macros. The cost > model is based on Juzhe's work. Understood. > > The point I am making is the auto-vectorization work is no more > experimental than the intrinsics work which is still being merged. I would disagree, though I do see your point. It's unfortunate that intrinsics work is still being merged -- I certainly wish that were not the case, but having agreed to the compromise earlier I personally feel that I need to let that process play out per that agreement. -- 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. Thoughts? jeff