Re: [5/9] Main target-independent support for direct interleaving

[Richard Guenther <richard.guenther@gmail.com>]

On Mon, Apr 18, 2011 at 2:19 PM, Richard Sandiford
<richard.sandiford@linaro.org> wrote:
> Richard Guenther <richard.guenther@gmail.com> writes:
>> On Mon, Apr 18, 2011 at 1:24 PM, Richard Sandiford
>> <richard.sandiford@linaro.org> wrote:
>>> Richard Guenther <richard.guenther@gmail.com> writes:
>>>> On Tue, Apr 12, 2011 at 3:59 PM, Richard Sandiford
>>>> <richard.sandiford@linaro.org> wrote:
>>>>> Index: gcc/doc/md.texi
>>>>> ===================================================================
>>>>> --- gcc/doc/md.texi     2011-04-12 12:16:46.000000000 +0100
>>>>> +++ gcc/doc/md.texi     2011-04-12 14:48:28.000000000 +0100
>>>>> @@ -3846,6 +3846,48 @@ into consecutive memory locations.  Oper
>>>>>  consecutive memory locations, operand 1 is the first register, and
>>>>>  operand 2 is a constant: the number of consecutive registers.
>>>>>
>>>>> +@cindex @code{vec_load_lanes@var{m}@var{n}} instruction pattern
>>>>> +@item @samp{vec_load_lanes@var{m}@var{n}}
>>>>> +Perform an interleaved load of several vectors from memory operand 1
>>>>> +into register operand 0.  Both operands have mode @var{m}.  The register
>>>>> +operand is viewed as holding consecutive vectors of mode @var{n},
>>>>> +while the memory operand is a flat array that contains the same number
>>>>> +of elements.  The operation is equivalent to:
>>>>> +
>>>>> +@smallexample
>>>>> +int c = GET_MODE_SIZE (@var{m}) / GET_MODE_SIZE (@var{n});
>>>>> +for (j = 0; j < GET_MODE_NUNITS (@var{n}); j++)
>>>>> +  for (i = 0; i < c; i++)
>>>>> +    operand0[i][j] = operand1[j * c + i];
>>>>> +@end smallexample
>>>>> +
>>>>> +For example, @samp{vec_load_lanestiv4hi} loads 8 16-bit values
>>>>> +from memory into a register of mode @samp{TI}@.  The register
>>>>> +contains two consecutive vectors of mode @samp{V4HI}@.
>>>>
>>>> So vec_load_lanestiv2qi would load ... ?  c == 8 here.  Intuitively
>>>> such operation would have adjacent blocks of siv2qi memory.  But
>>>> maybe you want to constrain the mode size to GET_MODE_SIZE (@var{n})
>>>> * GET_MODE_NUNITS (@var{n})?  In which case the mode m is
>>>> redundant?  You could specify that we load NUNITS adjacent vectors into
>>>> an integer mode of appropriate size.
>>>
>>> Like you say, vec_load_lanestiv2qi would load 16 QImode elements into
>>> 8 consecutive V2QI registers.  The first element from register vector I
>>> would come from operand1[I] and the second element would come from
>>> operand1[I + 8].  That's meant to be a valid combination.
>>
>> Ok, but the C loop from the example doesn't seem to match.  Or I couldn't
>> wrap my head around it despite looking for 5 minutes and already having
>> coffee ;)  I would have expected the vectors being in memory as
>>
>>   v0[0], v1[0], v0[1], v1[1], v2[0], v3[1]. v2[1], v3[1], ...
>>
>> not
>>
>>   v0[0], v1[0], v2[0], ...
>>
>> as I would have thought the former is more useful (simple unrolling for
>> stride 2).
>
> The second one's right.  All lane 0 elements, followed by all lane 1
> elements, etc.  I think that's what the C loop says.
>
>> We'd need a separate set of optabs for such an interleaving
>> scheme?  In which case we might want to come up with a more
>> specific name than load_lane?
>
> Yeah, if someone has a single instruction that does your first example,
> then it would need a new optab.  The individual vector pairs could be
> represented using the current optab though, if each pair needs a
> separate instruction.  E.g. with your v2qi example, vec_load_lanessiv2qi
> would load:
>
>   v0[0], v1[0], v0[1], v1[1]
>
> and you could repeat for the others.  So load_lanes (as defined here)
> could be treated as a primitive, and your first example could be something
> like "repeat_load_lanes".
>
> If you don't like the name "load_lanes" though, I'm happy to use
> something else.

Ah, no - repeat_load_lanes sounds a good name for the new optab if
we need it at any point.

Richard.

> Richard
>