llvm dev - Mar 2019 - Scalable Vector Types in IR - Next Steps?

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.

 -Hal
>
>                        -David
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190315/58d5a129/attachment.html>

> 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.
I view the situation differently, but I'm still relatively new to llvm-dev
and may be too unfamiliar with the threshold for inclusion in trunk, so please
help educate me.  I see people from more than one organization saying that
they'd like to see this in trunk.  No one wants it to be a drag on all
transforms because no one wants to have to rewrite a ton of code.  So it would
seem that there are two possible outcomes: it gets merged into trunk and the
interested parties try hard to not adversely impact all of LLVM because
that's in their best interest, too, OR it isn't merged and then we have
potentially the same multiple organizations maintaining support for this on the
side, out of trunk.  This community tries to avoid the latter situation, right? 
I've always thought of LLVM trunk as where code ends up that is useful to
multiple orgs and then each org maintains their own local patches for stuff that
no one else would want (or that they can't share for competitive reasons).

-Troy
________________________________
From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of Chandler
Carruth via llvm-dev <llvm-dev at lists.llvm.org>
Sent: Friday, March 15, 2019 3:55:26 PM
To: Finkel, Hal J.
Cc: Francesco Petrogalli via llvm-dev; Chandler Carruth; David Greene; Chris
Lattner; nd; Maxim Kuvyrkov
Subject: Re: [llvm-dev] Scalable Vector Types in IR - Next Steps?

On Fri, Mar 15, 2019 at 11:22 AM Finkel, Hal J. via llvm-dev <llvm-dev at
lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
On 3/15/19 10:58 AM, David Greene wrote:
> Renato Golin <rengolin at gmail.com<mailto: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<mailto: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.

-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190316/a23d0412/attachment.html>

"Finkel, Hal J." <hfinkel at anl.gov> writes:
> 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.
Graham, which patch(es) would you like to concentrate on for review
first?  A number are marked "not for review."  Do you need to update
them before we continue reviewing?

                        -David

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

Hi David,

I'll need to update the reviews (and rebase). I'll do that this week.

https://reviews.llvm.org/D32530 is the key patch. The backend codegen
patches can be safely ignored, I think -- we would want better isel
patterns.

It seems there's still some discussion to be had in this thread though.

-Graham
> On 18 Mar 2019, at 17:15, David Greene <dag at cray.com> wrote:
> 
> "Finkel, Hal J." <hfinkel at anl.gov> writes:
> 
>> 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.
> 
> Graham, which patch(es) would you like to concentrate on for review
> first?  A number are marked "not for review."  Do you need to
update
> them before we continue reviewing?
> 
>                        -David