llvm dev - Jul 2017 - [cfe-dev] Just a quick heads up -- removing BBVectorize from LLVM (and Clang)

Already added in the commit (I think)

On Fri, Jun 30, 2017 at 3:58 PM Hans Wennborg <hans at chromium.org>
wrote:
> On Thu, Jun 29, 2017 at 3:42 PM, Chandler Carruth via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > If you don't use BBVectorize at all, you can ignore this.
> >
> > Hal suggested this in a thread in 2014:
> > http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
> >
> > None objected then, and I don't think any new uses have arisen so
I plan
> to
> > just remove it. It is causing maintenance burden, complexity, and is a
> set
> > of features I'd rather not port to the new PM.
> >
> > Just an FYI email to folks so they aren't confused when the
patches land.
>
> Maybe worth mentioning in the release notes?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170701/d2a9a7cd/attachment.html>

I don't know how others feel, but it seems this was removed more by feeling
and less by actual data points. It doesn't mean it wasn't the correct
choice, but just because nobody spoke up could mean that they silently
enjoy the benefits and maybe some end user far away isn't subscribed. With
this in mind - I hope others would consider turning optimizations into an
Assert, Warning or Error if they will be removed - at least for a release.
That way there's some visible warning that users had a chance to see and
potentially relay the feedback. The middle ground could be disabling the
transformation and just warning on the analysis pass. "Foo optimization has
been removed and it may impact your code performance"...

Too much work?

On Sat, Jul 1, 2017 at 9:32 AM, Chandler Carruth via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> Already added in the commit (I think)
>
> On Fri, Jun 30, 2017 at 3:58 PM Hans Wennborg <hans at chromium.org>
wrote:
>
>> On Thu, Jun 29, 2017 at 3:42 PM, Chandler Carruth via cfe-dev
>> <cfe-dev at lists.llvm.org> wrote:
>> > If you don't use BBVectorize at all, you can ignore this.
>> >
>> > Hal suggested this in a thread in 2014:
>> > http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
>> >
>> > None objected then, and I don't think any new uses have arisen
so I
>> plan to
>> > just remove it. It is causing maintenance burden, complexity, and
is a
>> set
>> > of features I'd rather not port to the new PM.
>> >
>> > Just an FYI email to folks so they aren't confused when the
patches
>> land.
>>
>> Maybe worth mentioning in the release notes?
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20170701/6914f4e8/attachment.html>

On 06/30/2017 09:01 PM, C Bergström via cfe-dev wrote:
> I don't know how others feel, but it seems this was removed more by 
> feeling and less by actual data points. It doesn't mean it wasn't
the
> correct choice, but just because nobody spoke up could mean that they 
> silently enjoy the benefits and maybe some end user far away isn't 
> subscribed. With this in mind - I hope others would consider turning 
> optimizations into an Assert, Warning or Error if they will be removed 
> - at least for a release.
They'll get a warning about an unused command-line argument. Also, I 
think there's been some discussion about adding a more-specific warning 
for this case.

Thanks again,
Hal
> That way there's some visible warning that users had a chance to see 
> and potentially relay the feedback. The middle ground could be 
> disabling the transformation and just warning on the analysis pass. 
> "Foo optimization has been removed and it may impact your code 
> performance"...
>
> Too much work?
>
> On Sat, Jul 1, 2017 at 9:32 AM, Chandler Carruth via cfe-dev 
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>>
wrote:
>
>     Already added in the commit (I think)
>
>     On Fri, Jun 30, 2017 at 3:58 PM Hans Wennborg <hans at chromium.org
>     <mailto:hans at chromium.org>> wrote:
>
>         On Thu, Jun 29, 2017 at 3:42 PM, Chandler Carruth via cfe-dev
>         <cfe-dev at lists.llvm.org <mailto:cfe-dev at
lists.llvm.org>> wrote:
>         > If you don't use BBVectorize at all, you can ignore this.
>         >
>         > Hal suggested this in a thread in 2014:
>         >
>         http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html
>        
<http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html>
>         >
>         > None objected then, and I don't think any new uses have
>         arisen so I plan to
>         > just remove it. It is causing maintenance burden,
>         complexity, and is a set
>         > of features I'd rather not port to the new PM.
>         >
>         > Just an FYI email to folks so they aren't confused when
the
>         patches land.
>
>         Maybe worth mentioning in the release notes?
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
-- 
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

On Fri, Jun 30, 2017 at 7:01 PM, C Bergström via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> I don't know how others feel, but it seems this was removed more by
feeling
> and less by actual data points. It doesn't mean it wasn't the
correct
> choice, but just because nobody spoke up could mean that they silently
enjoy
> the benefits and maybe some end user far away isn't subscribed. With
this in
> mind - I hope others would consider turning optimizations into an Assert,
> Warning or Error if they will be removed - at least for a release. That way
> there's some visible warning that users had a chance to see and
potentially
> relay the feedback. The middle ground could be disabling the transformation
> and just warning on the analysis pass. "Foo optimization has been
removed
> and it may impact your code performance"...
>
> Too much work?
>
FWIW, people have independently found issues/miscompiles in the BB
Vectorizer. I picked up this only recently, but some of them have been
reported on bugzilla and been there forever without anybody looking at
them (see Zhendong's reports).
I don't think resurrecting would be hard if anybody really wants to.
It requires some amount of effort nobody is apparently able to put at
the moment. We removed loadcombine for a similar reason recently.

--
Davide