"juzhe.zh...@rivai.ai" <juzhe.zh...@rivai.ai> writes: > Hi, Richi. > >>> that should be > >>> || (!LOOP_VINFO_FULLY_MASKED_P (loop_vinfo) >>> && !LOOP_VINFO_FULLY_WITH_LENGTH_P (loop_vinfo)) > >>> I think. It seems to imply that SLP isn't supported with >>> masking/lengthing. > > Oh, yes. At first glance, the original code is quite suspicious and your > comments make sense to me. > >>> Hum, how does CFN_EXTRACT_LAST handle both mask and length transparently? >>> Don't you need some CFN_LEN_EXTRACT_LAST instead? > > I think CFN_EXTRACT_LAST always has either loop mask or loop len. > > When both mask and length are not needed, IMHO, I think current BIT_FIELD_REF > flow is good enough: > https://godbolt.org/z/Yr5M9hcc6
I'm a bit behind of email, but why isn't BIT_FIELD_REF enough for the case that the patch is handling? It seems that: .EXTRACT_LAST (len, vec) is equivalent to: vec[len - 1] I think eventually there'll be the temptation to lower/fold it like that. FWIW, I agree a IFN_LEN_EXTRACT_LAST/IFN_EXTRACT_LAST_LEN would be OK, with a mask, vector, length and bias. But even then, I think there'll be a temptation to lower calls with all-1 masks to val[len - 1 - bias]. So I think the function only makes sense if we have a use case where the mask might not be all-1s. Thanks, Richard
