[llvm-dev] Scalable Vector Types in IR - Next Steps?

Tue Mar 19 03:49:18 PDT 2019

Hi Bruce,

> On 19 Mar 2019, at 00:26, Bruce Hoult via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Three ISAs at present:
> 
> - SVE in Aarch64
> - MVE in ARM Cortex-M (quite different from SVE)
> - RVV in RISC-V

MVE isn't scalable in terms of registers (it's fixed at 128b iirc), so won't be using these types.

It can use execution units that are narrower than 128b, and start execution on partially
completed vectors in subsequent cycles (a bit like an RVV implementation might do when using
VLMul > 1, or the established vector supercomputer architectures).

Just a different set of design constraints.

As Simon and Erich point out though, SX-Aurora would like to use scalable vectors too, so
we still have three architectures intending to use the feature.

-Graham

> 
> It would not surprise me if other ISAs implement similar vector
> extensions in future.
> 
> On Mon, Mar 18, 2019 at 10:40 AM Eric Christopher via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> 
>> On Fri, Mar 15, 2019 at 1:55 PM Chandler Carruth via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>>> 
>>> On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>>>> 
>>>> On 3/15/19 10:58 AM, David Greene wrote:
>>>>> Renato Golin <rengolin at gmail.com> writes:
>>>>> 
>>>>>> On Fri, 15 Mar 2019 at 15:30, Finkel, Hal J. via llvm-dev
>>>>>> <llvm-dev at lists.llvm.org> wrote:
>>>>>>> I've talked with a number of people about this as well, and I think that
>>>>>>> I understand the objections. I'm happy that ARM followed through with
>>>>>>> the alternate set of patches. Regardless, however, unless those who had
>>>>>>> wished to object still wish to object, and then actually do so, we now
>>>>>>> clearly have a good collection of contributors actively desiring to do
>>>>>>> code review, and we should move forward (i.e., start committing patches
>>>>>>> once they're judged ready).
>>>>>> Let's start by closing the three flying revisions, so that people that
>>>>>> weren't involved in the discussion don't waste time looking at them.
>>>>> See the reply I just posted to Hal.  I am not sure we've made a decision
>>>>> to abandon the current patches.  We may in fact decide that, but I
>>>>> haven't seen consensus for doing so yet.  In fact I've seen the opposite
>>>>> -- that people want to move forward with the scalable types.
>>>> 
>>>> 
>>>> I agree with David. We should move forward with native support for
>>>> scalable types.
>>> 
>>> 
>>> Sorry I haven't been as available as usual for the past few weeks, but FWIW, I still am unconvinced that scalable vector types belong in the IR.
>>> 
>>> I think this adds complexity to LLVM's IR to serve a niche use case without proven benefit to a broad spectrum of hardware or software. I think the complexity is significant and will be a net drag on all parts of the IR and IR-level transformations. But I don't really think it is useful to re-hash all these debates. Nothing relevant has changed in the years this has been discussed.
>>> 
>>> That said, if I'm the only one who feels this way (and is willing to actually state this publicly), I'm not going to stop progress.
>>> 
>> 
>> You're not, and I'm in the same position here. I don't think there's a
>> really good answer for how this is going to affect a lot of the IR and
>> IR-level transformations from a maintainability perspective. It mostly
>> seems like this is a "we need this for the new ISA support" and while
>> I don't see a lot of compelling use case here and a lot of downside
>> that there...
>> 
>> -eric
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev