Oh. I made a mistake here. Forget about my last email.
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/634376.html Here is the V2 address comments as you suggested. Could you take a look ? Thanks. juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-10-26 17:25 To: Juzhe-Zhong CC: gcc-patches; rguenther Subject: Re: [PATCH] DOC: Update COND_LEN document Juzhe-Zhong <juzhe.zh...@rivai.ai> writes: > As Richard's suggested. We need to adapt doc for cond_len operations. > > gcc/ChangeLog: > > * doc/md.texi: Update document. Thanks for addressing my comment. I was thinking about the pseudo code though. Currently it is: for (i = 0; i < ops[4] + ops[5]; i++) op0[i] = op1[i] ? @var{op} op2[i] : op3[i]; but I think the outcome of the discussion was that it should instead be: for (i = 0; i < GET_MODE_NUNITS (@var{m}); i++) op0[i] = (i < ops[4] + ops[5] && op1[i] ? @var{op} op2[i] : op3[i]); to match internal-fn.cc. The binary and ternary optabs would need a similar update. Thanks, Richard > --- > gcc/doc/md.texi | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi > index daa318ee3da..dd2c26edf7b 100644 > --- a/gcc/doc/md.texi > +++ b/gcc/doc/md.texi > @@ -7400,6 +7400,8 @@ form of @samp{@var{op}@var{mode}2}. > @itemx @samp{cond_len_lshr@var{mode}} > When operand 1 is true and element index < operand 5 + operand 6, perform an > operation on operands 2 and 3 and > store the result in operand 0, otherwise store operand 4 in operand 0. > +operand 4 should be well-defined value for reduction situation, and > undefined value for some arithmetic operations > +e.g. integer division. > The operation only works for the operands are vectors. > > @smallexample
