[llvm-dev] [RFC] Vector Predication
Simon Moll via llvm-dev
llvm-dev at lists.llvm.org
Thu Feb 7 09:21:37 PST 2019
On 2/7/19 6:08 PM, David Greene wrote:
> Jacob Lifshay <programmerjake at gmail.com> writes:
>> So it would be handy for the vector length on evl intrinsics to be in
>> units of the mask length so we don't have to pattern match a division
>> in the backend. We could have 2 variants of the vector length
>> argument, one in terms of the data vector and one in terms of the mask
>> vector. we could legalize the mask vector variant for those
>> architectures that need it by pulling the multiplication out and
>> switching to the data vector variants.
> 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.
Allowing vector types as vector elements would solve the vlen
interpretation issue in an elegant way.
Researcher / PhD Student
Compiler Design Lab (Prof. Hack)
Saarland University, Computer Science
Building E1.3, Room 4.31
Tel. +49 (0)681 302-57521 : moll at cs.uni-saarland.de
Fax. +49 (0)681 302-3065 : http://compilers.cs.uni-saarland.de/people/moll
More information about the llvm-dev