[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths

[Robin Kruppe via llvm-dev]

On 2 August 2018 at 00:25, Hal Finkel <hfinkel at anl.gov> wrote:
>
> On 08/01/2018 03:09 PM, Robin Kruppe wrote:
>> ...
>>> I think that this will likely work, although I think we want to invert
>>> the sense of the attribute. vscale should be inherited by default, and
>>> some attribute can say that this isn't so. That same attribute, I
>>> imagine, will also forbid scalable vector function arguments and return
>>> values on those functions. If we don't have inherited vscale as the
>>> default, we place an implicit contract on any IR transformation hat
>>> performs outlining that it needs to scan for certain kinds of vector
>>> operations and add the special attribute, or just always add this
>>> special attribute, and that just becomes another special case, which
>>> will only actually manifest on certain platforms, that it's best to avoid.
>> It's a real relief to hear that you think this "will likely work".
>>
>> Inverting the attribute seems good to me. I probably proposed not
>> inheriting by default because that's the default on RISC-V, but your
>> rationale is convincing.
>>
>>>> Modelling the dynamic vector length for RVV is something for Robin (or others) to tackle later, but can be though of (at a high level) as an implicit predicate on all operations.
>>> My point is that, while there may be some sense in which the details can
>>> be worked out later, we need to have a good-enough understanding of how
>>> this will work now in order to make sure that we're not making design
>>> decisions now that make handling the dynamic vscale in a reasonable way
>>> later more difficult.
>> Sorry if I'm a broken record, but I believe Graham was referring to
>> the _active vector length_ or VL here, which has nothing to do with
>> vscale, dynamic or not. I described earlier why I think the former
>> doesn't interact with the contents of this RFC in any interesting way.
>> If you think otherwise, could you elaborate on why you think that?
>
> Was it decided that this issue is equivalent to, or a subset of,
> per-lane predication on load, stores, and similar? Or is it different?

It is equivalent a subset. If there are k lanes, vector instructions
execute under a mask that enables the first VL lanes and disables the
remaining (k - VL) lanes. That same mask is computed by SVE
instructions such as whilelt. This style of predication can be
combined with a more conventional and more general one-bit-per-lane
mask, then the instruction executes under the conjunction of these two
masks.


Cheers,
Robin

> Thanks again,
> Hal
>
>>
>>
>> Cheers,
>> Robin
>>
>>> Thanks again,
>>> Hal
>>>
>>>> -Graham
>>>>
>>>>> Thanks again,
>>>>> Hal
>>>>>
>>>>> --
>>>>> Hal Finkel
>>>>> Lead, Compiler Technology and Programming Languages
>>>>> Leadership Computing Facility
>>>>> Argonne National Laboratory
>>>>>
>>> --
>>> Hal Finkel
>>> Lead, Compiler Technology and Programming Languages
>>> Leadership Computing Facility
>>> Argonne National Laboratory
>>>
>
> --
> Hal Finkel
> Lead, Compiler Technology and Programming Languages
> Leadership Computing Facility
> Argonne National Laboratory
>