https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #25 from JuzheZhong <juzhe.zhong at rivai dot ai> --- (In reply to rsand...@gcc.gnu.org from comment #24) > Heh, nice hack. :) But I guess this shows that the type checking of > internal functions isn't as strong it should be. > > IMO it's wrong to pass a scalar else value to a vector operation. > Even if it happens to work now, it's likely to fail in the future. > E.g. I think match.pd fold rules should be entitled to assume > (without checking) that all data operands to a COND_* function > have compatible types. > > If we want an undefined operand value, I think we'll need add to > add one that specifically has that meaning. 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. Adding undefine value will be the optimal solution. However, it will be a big project: 1. Add undefine in tree.def 2. Add undefine in RTL representation. 3. Adjust each PASS to handle undefine value. 4. Adjust register allocation to handle undefine value. ... etc I can image it will be long term project to support undefine. But we want to fix this inferior codegen of RVV currently since I have tested various benchmark, the ELSE value hurt the performance so much so that I want to use current infrastructure GCC to fix this issue.
