Andrew Stubbs <a...@codesourcery.com> 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
