On Tue, 26 May 2020, Segher Boessenkool wrote: > Hi! > > On Tue, May 26, 2020 at 01:29:30PM +0100, Richard Sandiford wrote: > > FWIW, I agree adding .LEN_LOAD and .LEN_STORE seems like a good > > approach. I think it'll be more maintainable in the long run than > > trying to have .MASK_LOADs and .MASK_STOREs that need a special mask > > operand. (That would be too similar to VEC_COND_EXPR :-)) > > > > Not sure yet what the exact semantics wrt out-of-range values for > > the IFN/optab though. Maybe we should instead have some kind of > > abstract, target-specific cookie created by a separate intrinsic. > > Haven't thought much about it yet... > > Or maybe only support 0..N with N the length of the vector? It is > pretty important to support 0 and N, but greater than N isn't as > important (it is useful for tricky hand-written code, but not as much > for compiler-generate code -- we only support an 8-bit number here on > Power, maybe that is why ;-) )
The question is one of semantics - if power masks the length to an 8 bit number it's important to preprocess the IV. As with my other suggestion the question is what to expose to the IL (to GIMPLE) here. Exposing as much as possible will help IV selection but will eventually require IFN variations for different semantics. So yes, 0..N sounds about right here and we'll require a MIN () operation and likely need to teach IV selection about this to at least possibly get an IV with the byte size multiplication factored. Richard. > > Segher > -- Richard Biener <rguent...@suse.de> SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany; GF: Felix Imendörffer; HRB 36809 (AG Nuernberg)
