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

[Chandler Carruth via llvm-dev]

On Wed, Mar 27, 2019 at 4:40 PM Finkel, Hal J. <hfinkel at anl.gov> wrote:

> On 3/27/19 4:33 PM, Sebastian Pop via llvm-dev wrote:
> > I am of the opinion that handling scalable vectors (SV)
> > as builtins and an opaque SV type is a good option:
> >
> > 1. The implementation of SV with builtins is simpler than changing the
> IR.
> >
> > 2. Most of the transforms in opt are scalar opts; they do not optimize
> > vector operations and will not deal with SV either.
> >
> > 3. With builtins there are fewer places to pay attention to,
> > as most of the compiler is already dealing with builtins in
> > a neutral way.
> >
> > 4. The builtin approach is more targeted and confined: it allows
> > to amend one optimizer at a time.
> > In the alternative of changing the IR, one has to touch all the
> > passes in the initial implementation.
>
>
> Interestingly, with similar considerations, I've come to the opposite
> conclusion. While in theory the intrinsics and opaque types are more
> targeted and confined, this only remains true *if* we don't end up
> teaching a bunch of transformations and analysis passes about them.
>

While I continue to disagree with Hal about whether we want this at all,
FWIW I agree on this specific point.

*If* we are going to end up teaching a bunch of transformations about
these, I think it will in many case be preferable to have them in the IR.

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.

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