On Wed, May 27, 2020 at 09:25:43AM +0200, Richard Biener wrote: > On Tue, 26 May 2020, Segher Boessenkool wrote: > > 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.
In the instructions it *is* an 8 bit number (it is the top 8 bits of a GPR). > As with my > other suggestion the question is what to expose to the IL (to GIMPLE) > here. Yes, I understand that. Hence my answer :-) Only multiples of element size would be fine as well of course. > 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. Maybe we should have a hook to say which lengths are allowed for which element type? And, how does this work for variable lengths (the usual case!) Segher
