https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> --- (In reply to JuzheZhong from comment #15) > I am wondering: do we have have other situations need "undef" value to do > optimizations? If yes, I am aggree with Richard that we need to support > "undef" > value. But "undef" value in Gimple IR support would be a long term work > since it > is not an easy job. For example, in llvm, undef + a -> undef, but undef & a > -> 0. We do have "undef" in the GIMPLE IR, for SSA variables it's the default definition. Note I think that a formal "undef" is different from "unspecified" (or in this case "target specified"). In GIMPLE an "undef" use is invoking undefined behavior but clearly doing a MASK/LEN operation with some "undef" lanes and then operating on the vector is _not_ invoking undefined behavior. In fact with RVV intrinsics the programmer can rely on RVV semantics, thus either all-ones _or_ merge which means if you know the old value has some specific bits set you know the new value will as well. That's _not_ "undef" in the classical sense so I think LLVMs "undef" isn't a very good fit here (nor would putting a SSA default def as the "else" value).
