https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Thu, 20 Jul 2023, kito at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110751 > > --- Comment #4 from Kito Cheng <kito at gcc dot gnu.org> --- > > OK, so TA is either merge or all-ones. > > Yes, your understand is correct, just few more detail is that can be mixing > with either merge or all-ones. > > e.g. > > An 4 x i32 vector with mask 1 0 1 0 > > Op = | a | b | c | d | > Mask = | 1 | 0 | 1 | 0 | > > the result could be: > | a | b | c | d | > | a | all-1 | c | d | > | a | all-1 | c | all-1 | > | a | all-1 | c | d | > > > > Not sure how you can use MA at the moment since you specify an existing > > operand in your target hook. As far as > > I can see there's no value the target hook can provide that matches any > of the implementation semantics? > > That's the key point - we don't know how to return an undefined value there, > we > have intrinsic can generate undefined value, but it seems impossible to > generate that within the hook. Well, neither *A nor *U can be specified currently. As said for 'merge' we would need another operand. And since 'unspecified' is either merge or all-ones we can't express that either. It's not really 'undefined' either. Note this also means the proposal to define a .MASK_LOAD as zeroing masked elements is not going to work for RISC-V, instead we'd need an explicit 'else' value there as well. In fact we could follow .MASK_LOAD for .COND_* and simply omit the 'else' operand for the case of 'unspecified', no? GIMPLE would be fine omitting it, not sure whether there's precedent for optabs with optional operands?
