From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id E8ED83858D28 for ; Thu, 29 Sep 2022 10:17:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E8ED83858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 30BAE1477; Thu, 29 Sep 2022 03:17:59 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C89993F73B; Thu, 29 Sep 2022 03:17:51 -0700 (PDT) From: Richard Sandiford To: Andrew Stubbs Mail-Followup-To: Andrew Stubbs ,Richard Biener via Gcc-patches , Richard Biener , , richard.sandiford@arm.com Cc: Richard Biener via Gcc-patches , Richard Biener , Subject: Re: [PATCH] vect: while_ult for integer mask References: <87180de9-d0d4-b92f-405f-100aca3d5cf8@codesourcery.com> Date: Thu, 29 Sep 2022 11:17:50 +0100 In-Reply-To: (Andrew Stubbs's message of "Thu, 29 Sep 2022 10:56:57 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-40.7 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: Andrew Stubbs writes: > On 29/09/2022 10:24, Richard Sandiford wrote: >> Otherwise: >> >> operand0[0] = operand1 < operand2; >> for (i = 1; i < operand3; i++) >> operand0[i] = operand0[i - 1] && (operand1 + i < operand2); >> >> looks like a "length and mask" operation, which IIUC is also what >> RVV wanted? (Wasn't at the Cauldron, so not entirely sure.) >> >> Perhaps the difference is that in this case the length must be constant. >> (Or is that true for RVV as well?) > > I too saw that presentation and I have compared notes with Juzhe before > posting this. > > As he has posted, what they want is different because their config > register has an explicit length field whereas GCN just uses a mask to > limit the length (more like AArch64, I think). > > The RVV solution uses different logic in the gimple IR; this proposal is > indistinguishable from the status quo at that point. Hmm, OK. (And thanks to Juzhe for the summary.) I can't think of any existing examples of optabs that have a variable number of operands. But maybe this is a good reason to change that. Having to add what amounts to a vector type descriptor to make up for the lack of mode information seems like a bit of a hack. But it's possibly a hack that we'll need to do again (for other patterns), if we keep representing multiple distinct vector/predicate types using the same integer mode. I guess this establishes a way of coping with the situation in general. So personally I'm OK with the patch, if Richi agrees. Richard