[llvm-dev] [RFC][SVE] Supporting SIMD instruction sets with variable vector lengths
Hal Finkel via llvm-dev
llvm-dev at lists.llvm.org
Wed Aug 1 15:25:12 PDT 2018
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?
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
More information about the llvm-dev
mailing list