From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x636.google.com (mail-ej1-x636.google.com [IPv6:2a00:1450:4864:20::636]) by sourceware.org (Postfix) with ESMTPS id 5C6C33858D39 for ; Thu, 29 Sep 2022 13:46:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C6C33858D39 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-ej1-x636.google.com with SMTP id lc7so2979568ejb.0 for ; Thu, 29 Sep 2022 06:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date; bh=RaC/DQFswm4gMmHxaBCrDy4NH/NX0bz8juBfMHYWGUE=; b=FpwIxuYFYquJC08sJzMe/uzdkd71+UIdoai0LXTbpYl7dytYZ8ROVG8P0bv0+GdG7O QPQLykX3fxQ1C1bAi6YD5tQG/0GHQuXH4elLJO6E9WQPqV5SEqYxKR48Qnf0WIpvXXfS xaaiyJnGkIGSezLMoEQ1QP/Jej62bJoJAB5P/8wMuGb/7S8iyz96Z3RxP5lvFSAZaw51 6i8hphLXQzZsDa150a+tvBwV+Rw0reSzeLsUTvPcT2AVJ+JtMCt8BlnnmUJk0rjo/oLe SMDn7BabqTJo9yTQBJkU6uBoHPXsm9cjzyWBTEwhRIYejAFQlJq3bx/IqyKa4zh04zaF uDzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date; bh=RaC/DQFswm4gMmHxaBCrDy4NH/NX0bz8juBfMHYWGUE=; b=6yTEn+uVYOKRzLQHxu5b7JSzkjxg32mkQDEz945Johk5NKKAzAXBEanl5fZhNJh7+Y LToiF3eiMyxjSzh+QugZkaywMB3yWDGsBPZylCbRpm+PxEyvsIQzv/IrPg7uHSh3bpDP Fr1mnsC+KeKPrtAYMqyr18l4sJZDbB4T8T2zt+OFwogtnsrHJX7gszysrkVsI8aXvL5X 20oi343UNt0yqnBY9Wa1BxJvwcFJnQ7Mb9N5UDbdAB/l6U02BY4SFkqz3n1p9E1Qkciy Efj+8XioIoqEn8zE5ynC710n1suKRo+bhqSjnZdgg6+ZG+IbC8z7qTw3v1LyF4Ih424l sRJg== X-Gm-Message-State: ACrzQf36/s7z1vC23VH5HGbGICAii08aWxveapSshFMWGmqkPUERn+34 dn5kzb/IeGYIe6elYjuIdAj1H6FyVQ3Xf3i0yoM= X-Google-Smtp-Source: AMsMyM5Xfm7NNn8ncLfwh5FcNJ3boZuwNj044Fw77aBsWVw1AQWHEHzBEy1+sUiqcxt47Ihnm//7RId7QKjdZKIkB5U= X-Received: by 2002:a17:907:7632:b0:76f:f6e7:36cf with SMTP id jy18-20020a170907763200b0076ff6e736cfmr2859644ejc.442.1664459190955; Thu, 29 Sep 2022 06:46:30 -0700 (PDT) MIME-Version: 1.0 References: <87180de9-d0d4-b92f-405f-100aca3d5cf8@codesourcery.com> In-Reply-To: From: Richard Biener Date: Thu, 29 Sep 2022 15:46:18 +0200 Message-ID: Subject: Re: [PATCH] vect: while_ult for integer mask To: Andrew Stubbs , Richard Biener via Gcc-patches , Richard Biener , juzhe.zhong@rivai.ai, richard.sandiford@arm.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Thu, Sep 29, 2022 at 12:17 PM Richard Sandiford wrote: > > 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. It's not the nicest way of carrying the information but short of inventing new modes I can't see something better (well, another optab). I see the GCN backend expects a constant in operand 3 but the docs don't specify the operand has to be a CONST_INT, can you adjust them accordingly? Otherwise I'm fine with it. It might even prove useful for x86. Richard. > Richard