https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #27 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (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).
