public inbox for
 help / color / mirror / Atom feed
From: Richard Sandiford <>
To: Andrew Stubbs <>
Cc: Richard Biener via Gcc-patches <>,
	 Richard Biener <>,
Subject: Re: [PATCH] vect: while_ult for integer mask
Date: Thu, 29 Sep 2022 11:17:50 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Andrew Stubbs's message of "Thu, 29 Sep 2022 10:56:57 +0100")

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.


  reply	other threads:[~2022-09-29 10:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-28 15:05 Andrew Stubbs
2022-09-29  7:52 ` Richard Biener
2022-09-29  9:24   ` Richard Sandiford
2022-09-29  9:37     ` Richard Biener
2022-09-29  9:38     ` juzhe.zhong
2022-09-29  9:56     ` Andrew Stubbs
2022-09-29 10:17       ` Richard Sandiford [this message]
2022-09-29 13:46         ` Richard Biener
2022-10-03 14:27           ` Andrew Stubbs
2022-09-29  9:50   ` Andrew Stubbs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).