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 rsand...@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.
