https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #21 from rguenther at suse dot de <rguenther at suse dot de> --- On Fri, 21 Jul 2023, rsandifo at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 > > --- Comment #20 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot > gnu.org> --- > (In reply to Richard Biener from comment #19) > > Sure, I can kind of see the usefulness elsewhere. Just for this particular > > issue it doesn't seem necessary to sit down and design this when we can > > represent it like we do for MASK_LOAD (omit the 'else' value). > Yeah, that's fair. > > For the ifn->optab interface, I think it'd be natural to use an actual rtx > rather than a null pointer, since e.g. predicates are not set up to handle > nulls. So perhaps we should start the process there. We could add an UNDEF > rtl code that is initially only used for the ifn->optab interface, and expand > it as we find new use cases. We can grow the semantics based on those use > cases and based on LLVM's experience. > > > In other context we discussed specifying zero for MASK_LOAD masked elements > > so we can for example CSE better. CSE with UNDEF might be possible as well, > > but I'm not sure what LLVM's undef would allow and whether it's defined > > rigidly enough. > One of the main optimisations I wanted from that was: > a = IFN_MASK_LOAD (?, mask) > b = VEC_COND_EXPR <mask, a, {0,0,?}> > ? > a = IFN_MASK_LOAD (?, mask) > b = a > which wouldn't be valid for undef. Right. It would be valid to do b = IFN_MASK_LOAD (?, mask, {0,0,?}); if we add ELSE to IFN_MASK_LOAD.
