[Bug target/110751] RISC-V: Suport undefined value that allows VSETVL PASS use TA/MA

["juzhe.zhong at rivai dot ai" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751

--- Comment #28 from JuzheZhong <juzhe.zhong at rivai dot ai> ---
(In reply to JuzheZhong from comment #27)
> (In reply to rsandifo@gcc.gnu.org from comment #26)
> > But this is how technical debt builds up.  We'd be making a change
> > that doesn't match the type system, and that we know to be wrong
> > in principle.  And we'd be making it with no realistic prospect
> > that it will be cleaned up later.
> > 
> > > Yes. I am also worrying about GIMPLE_FOLD stuff will check all arguments
> > > type are compatible for COND_LEN_xxx in the future (Currently, it's obviously
> > > not checking this). Then, it will cause ICE.
> > 
> > Yeah.  But like I say, I don't think that's the most worrying
> > scenario.  For me the most worrying scenario is that a match.pd
> > fold will say that:
> > 
> >   (cond_len all-false a b c len bias)
> > 
> > folds to c without checking whether c is compatible with the return
> > type.  And IMO it shouldn't need to check that the type is compatible.
> > 
> > If a rule like that triggers after this patch goes in, the pressure
> > will be to continue to support the hack and add workarounds for it.
> 
> Thanks Richard a lot.
> 
> But I don't think we need to worry about the fold COND_LEN into
> the ELSE_VALUE.
> 
> Let's back to the previous comments you gave for COND_LEN_xxx:
> https://gcc.gnu.org/pipermail/gcc-patches/2023-July/625396.html
> 
> Following your suggestions, I support cond_len_xxx by following your (1):
> 
> (1) RVV implements cond_* optabs as expanders.  RVV therefore supports
>     both IFN_COND_ADD and IFN_COND_LEN_ADD.  No dummy length arguments
>     are needed at the gimple level.
> 
> I use this approach to support COND_LEN_xxx since last time you have
> mentioned
> we will need more work in GIMPLE FOLD and other things.
> 
> To simplify the implementation of COND_LEN_xxx. We support both COND_XXX and
> COND_LEN_XXX in RISC-V backend. 
> 
> We don't have COND_LEN_xxx with dummy length (All dummy length case will go
> back to COND_XXX).  So we forbid the case that FOLD COND_LEN_xxx into ELSE
> value since COND_LEN_xxx is built always with a meaning length.
> 
> The only GIMPLE FOLD optimization of COND_LEN_XXX is operations fusion,
> meaning
> FOLD cond_len_mult + cond_len_add into ==> cond_len_fma. That's what I am
> worry about. But currently it works fine (I have tests to test that).

Moreover, Maybe we will need to worry about COND_XXX into ELSE_VALUE if I
return
scalar 0 in the else targethook.

However, for RVV, we always use COND_LEN_xxx in the loop vectorizer which may
build with the argument from the ELSE_VALUE targethook.

The only situation we will use COND_XXX is the UNCOND_OP + VEC_COND_EXPR ->
COND_XXX in match.pd which always has a real ELSE VALUE.

After these analysis, it seems that there is no risks?

Not sure whether I am correct or not.