[llvm-dev] [RFC] Vector Predication (original) (raw)

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 >. 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.

                                -David

More information about the llvm-dev mailing list