[llvm-dev] [RFC] Vector Predication

David Greene via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 8 07:34:56 PST 2019

Jacob Lifshay <programmerjake at gmail.com> writes:

>     > Would it make sense to have two different intrinsics?
>     >
>     > # "Normal" form, L is in terms of flat vector length.
>     > <scalable 2 x float> evl.fsub(<scalable 2 x float> %x,
>     > <scalable 2 x float> %y,
>     > <scalable 2 x i1> %M, i32 %L)
>     >
>     > # "Sub-vector" form, L is in terms of sub-vectors elements.
>     > <scalable 1 x <2 x float>> evl.fsub(<scalable 1 x <2 x float>>
>     %x,
>     > <scalable 1 x <2 x float>> %y,
>     > <scalable 1 x <2 x i1>> %M, i32 %L
>     >
>     > Overloading types to mean two very different things is confusing
>     to me.
>     >
>     > -David
>     Allowing vector types as vector elements would solve the vlen 
>     interpretation issue in an elegant way.
> This seems like the best solution, though maybe out of scope of the
> current evl proposal. This would also create a decent IR
> representation of a matrix or other 2D vector: matMxN would be <N x <M
> x float>>.
> While we're adding this, it may be a good idea to go all in and just
> lift the restriction on vectors containing other non-scalable vectors,
> so you could do something like: <scalable 1 x <4 x <4 x float>>> to be
> a scalable vector of 4x4 matrices.

This is enticing to me but it does give me pause about how SIMD targets
will deal with these types.  This needs a lot more thought before we
make a decision.

This could also be useful for representing complex type operations with
appropriate intrinsics.

I agree that it may be out of scope for the EVL proposal, but if EVL
goes ahead it would seem that it won't initially support the sub-vector
operations without special intrinsics.


More information about the llvm-dev mailing list