Things have moved on due to the IRC conversation, but…
"Kewen.Lin" <li...@linux.ibm.com> writes:
> on 2020/6/23 上午3:59, Richard Sandiford wrote:
>> "Kewen.Lin" <li...@linux.ibm.com> writes:
>>> @@ -5167,6 +5167,24 @@ mode @var{n}.
>>>
>>> This pattern is not allowed to @code{FAIL}.
>>>
>>> +@cindex @code{lenload@var{m}} instruction pattern
>>> +@item @samp{lenload@var{m}}
>>> +Perform a vector load with length from memory operand 1 of mode @var{m}
>>> +into register operand 0. Length is provided in register operand 2 with
>>> +appropriate mode which should afford the maximal required precision of
>>> +any available lengths.
>>
>> I think we need to say in more detail what “load with length” actually
>> means. How about:
>>
>> Load the number of bytes specified by operand 2 from memory operand 1
>> into register operand 0, setting the other bytes of operand 0 to
>> undefined values. Operands 0 and 1 have mode @var{m}. Operand 2 has
>> whichever integer mode the target prefers.
>>
>
> Thanks for nice wordings! Updated, for "... to undefined values" I changed it
> to "... to undefined values or zeros" as Segher's comments to match the
> behavior
> on Power.
“set … to undefined values” means that the values are not defined by
the optab interface. In other words, the target can set the bytes
to whatever it wants, and gimple code can't make any assumptions about
what the values of the bytes are.
So setting the bytes to zero (as Power does) would conform to the
interface. So would leaving the bytes in operand 0 untouched.
So would using an instruction that really does leave the other
bytes with undefined values, etc.
So I think we should keep it as just “… to undefined values”,
The alternative would be to define the interface so that targets *must*
ensure that the other bytes are zeros. But at the moment, the only
intended use of the optabs and ifns is for autovectorisation, and the
vectoriser won't care about the values of “inactive” bytes/lanes.
Forcing the target to set them to a specific value like zero would be
unnecessarily restrictive.
Thanks,
Richard
