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

On Wed, Mar 27, 2019 at 6:46 PM Chandler Carruth <chandlerc at gmail.com>
wrote:
> Using intrinsics and an opaque type, IMO, makes the most sense as a
pass-through mechanism for allowing very limited usage without investing in any
significant mid-level analysis or transformation awareness.
Ok, so if there are just a few passes to be amended, we may want to go
the opaque type route.

Can we list the passes that do something to the current vector types?
InstCombine
Vectorizer
...
Those passes will be immediate candidates to be taught about SV.
Any other pass/analysis like GVN for vectors is pie in the sky.


Sebastian

On 3/27/19 9:45 PM, Sebastian Pop wrote:
> On Wed, Mar 27, 2019 at 6:46 PM Chandler Carruth <chandlerc at
gmail.com> wrote:
>> Using intrinsics and an opaque type, IMO, makes the most sense as a
pass-through mechanism for allowing very limited usage without investing in any
significant mid-level analysis or transformation awareness.
> Ok, so if there are just a few passes to be amended, we may want to go
> the opaque type route.
>
> Can we list the passes that do something to the current vector types?
> InstCombine

I'm not sure that counting passes is meaningful so much as the amount of
code. How much of InstCombine works on vector types I don't know, but
InstCombine+InstructionSimplify is nearly 38k lines.

> Vectorizer
> ...
> Those passes will be immediate candidates to be taught about SV.
> Any other pass/analysis like GVN for vectors is pie in the sky.

Given that our GVN does not just do value numbering, but also does a lot
of our store-to-load forwarding (and, in fact, our current GVN spends
most of its time doing this), I think it's highly likely that we'd want
to teach GVN how to deal with these types. We do already have a special
infrastructure for doing this kind of thing for
target-intrinsic-returned values within EarlyCSE, and that would likely
be enhanced as well. This asymmetry in capabilities between EarlyCSE and
GVN isn't good, and you could make the argument that using it in GVN,
and thus using this mechanism to teach GVN about SV intrinsics would
also be a good thing, but regardless, one way or the other, I see it as
more likely than not that GVN is also affected.

 -Hal

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

I had a phone conversation yesterday with Graham, Francesco,
and Kristof.

There is one more reason to go with the native type change:
ARM has already written the code with the SV types, and they
have patches ready to be reviewed and integrated in LLVM.

As I don't want to stand in the way of getting SVE in LLVM
as soon as possible, I will also support the integration of the
existing patches and I will help with the review.

Sebastian