Yeah. I think Robin may need this : TREE_CODE (else_val) == SSA_NAAME && SSA_NAME_IS_DEFAULT_DEF (else_val) && VAR_P (SSA_NAME_VAR (else_val)) to differentiate whether the ELSE VALUE is uninitialized SSA or not.
juzhe.zh...@rivai.ai From: Richard Sandiford Date: 2023-10-26 06:32 To: 钟居哲 CC: gcc-patches; rdapp.gcc; rguenther Subject: Re: [PATCH] internal-fn: Add VCOND_MASK_LEN. 钟居哲 <juzhe.zh...@rivai.ai> writes: >>> Which one is right? > Hi, Richard. Let me explain this situation. > > Both situations are possible. It's depending on the 'ELSE' value whether it > is unitialized value. > > For reduction case: > > for (int i = 0; i < n; i++) > result += a[i] > > The trailing elements should be well-defined, keep the original value. > Otherwise, it will cause run-time issue. > > For integer DIV operation: > > for (int i = 0; i < n; i++) > a[i] = a[i] / b[i]; > > The trailling elements are DON'T care (or undefined), I will use unitialized > value in 'ELSE' value. > Then later 'expand' stage will expand it into "clobber scratch" RTL. OK, in that case it sounds like we're talking about PR110751. The gimple semantics are that the COND_LEN operates on all lanes of the mode (and the md.texi documentation should be fixed). But if the else value is undefined, we can simplify: IFN_COND_LEN_IOR (mask, a, 0, undef, len, bias) to "a". That's not really a property of COND_LEN though. The same thing applies to plain IFN_COND_IOR. If the fold reduces to a selection between two values, and one of them is undefined, we can pick the other. (Although we'd need to think a little carefully about that, c.f. llvm's distinction between undef and poison.) Thanks, Richard