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

[Finkel, Hal J. via llvm-dev]

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