llvm dev - Sep 2020 - Vector evolution?

On Tue, Sep 1, 2020 at 5:10 PM Florian Hahn <florian_hahn at apple.com>
wrote:
> The loop vectorizer does not really handle loops that already operate on
vectors, so that is why the loop using v4f32 does not get widened.
>
> Arguably the user explicitly asked for 4xfloat vectors in the v4f32
version, so that is what gets generated.
In my case I have tons of legacy code written for SSE2 and if the
compiler can make a better and correct version of it, why not?
> (Those kinds of issues are better to discuss on https://bugs.llvm.org/ IMO,
because it is easier to keep track of the progress on the issue).
That is noted, but I can't think of it as a bug unless I understand the
issue.

Thank you Florian,
-- 
Alexandre BIQUE

> On Sep 1, 2020, at 16:23, Alexandre Bique <bique.alexandre at
gmail.com> wrote:
> 
> On Tue, Sep 1, 2020 at 5:10 PM Florian Hahn <florian_hahn at
apple.com> wrote:
>> The loop vectorizer does not really handle loops that already operate
on vectors, so that is why the loop using v4f32 does not get widened.
>> 
>> Arguably the user explicitly asked for 4xfloat vectors in the v4f32
version, so that is what gets generated.
> 
> In my case I have tons of legacy code written for SSE2 and if the
> compiler can make a better and correct version of it, why not?
Right, that’s also a reasonable argument. 

Cases like those should get unrolled sufficiently already and all that needs to
be done is combining multiple instructions to their wider versions. This can
probably be done relatively easily in either the SLP vectorizer [1]  or
VectorCombine [2[

[1]
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
[2]
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Vectorize/VectorCombine.cp
>> (Those kinds of issues are better to discuss on https://bugs.llvm.org/
IMO, because it is easier to keep track of the progress on the issue).
> 
> That is noted, but I can't think of it as a bug unless I understand the
issue.
I would not say it is a bug, but rather a missing transform. The naming of
https://bugs.llvm.org/ might imply that it is only for bugs, but in practice it
is used to collect missed optimizations, suggestions for new features and so on
as well.

Cheers,
Florian

I have no idea how well this code was tested, but some researchers already
wrote an LLVM pass that does exactly what is requested:
https://github.com/revec/llvm-revec
See the linked paper that they published for their experimental results.

On Tue, Sep 1, 2020 at 11:51 AM Florian Hahn via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
>
>
> > On Sep 1, 2020, at 16:23, Alexandre Bique <bique.alexandre at
gmail.com>
> wrote:
> >
> > On Tue, Sep 1, 2020 at 5:10 PM Florian Hahn <florian_hahn at
apple.com>
> wrote:
> >> The loop vectorizer does not really handle loops that already
operate
> on vectors, so that is why the loop using v4f32 does not get widened.
> >>
> >> Arguably the user explicitly asked for 4xfloat vectors in the
v4f32
> version, so that is what gets generated.
> >
> > In my case I have tons of legacy code written for SSE2 and if the
> > compiler can make a better and correct version of it, why not?
>
> Right, that’s also a reasonable argument.
>
> Cases like those should get unrolled sufficiently already and all that
> needs to be done is combining multiple instructions to their wider
> versions. This can probably be done relatively easily in either the SLP
> vectorizer [1]  or VectorCombine [2[
>
> [1]
>
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Vectorize/SLPVectorizer.cpp
> [2]
>
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/Vectorize/VectorCombine.cp
>
> >> (Those kinds of issues are better to discuss on
https://bugs.llvm.org/
> IMO, because it is easier to keep track of the progress on the issue).
> >
> > That is noted, but I can't think of it as a bug unless I
understand the
> issue.
>
> I would not say it is a bug, but rather a missing transform. The naming of
> https://bugs.llvm.org/ might imply that it is only for bugs, but in
> practice it is used to collect missed optimizations, suggestions for new
> features and so on as well.
>
> Cheers,
> Florian
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/d4aac263/attachment.html>