On Tue, Jun 23, 2020 at 11:53 AM Richard Sandiford
<richard.sandif...@arm.com> wrote:
>
> 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.
Actually it _does_ care. This is supposed to be used for fully masked
loops and 'unspecified values' would require us to explicitely zero
them for any FP op because of possible sNaN representations. It
also precludes us from bitwise ORing in an appropriately masked
vector of 1s to make integer division happy (OK, no vector ISA supports
integer division).
So unless we have evidence that there exists an ISA that does _not_
zero the excess bits I'd rather specify it does.
Richard.
>
> Thanks,
> Richard
