[llvm-dev] [RFC] Vector Predication

Jacob Lifshay via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 04:14:24 PST 2019


On Mon, Feb 4, 2019, 03:46 Simon Moll <moll at cs.uni-saarland.de wrote:

> On 2/2/19 1:39 AM, Luke Kenneth Casson Leighton wrote:
>
>
>
> On Friday, February 1, 2019, Simon Moll <moll at cs.uni-saarland.de> wrote:
>>
>> We could untie the mask length from the data length:
>>
>>   %result = call <scalable 4 x float> @llvm.evl.fsub.v4f32(<scalable 4 x
>> float> %x, <scalable 4 x float> %y, <scalable 1 x i1> %M, i32 %L)
>>
>> would then indicate the mask %M applies to groups of "4 / 1" float
>> elements.
>>
>
> That would provide the greatest flexibility, as a 1:1 ratio could mean 1
> bit per element, covering the normal case.
>
> Question: are there any circumstances under which it is desirable to
> underspecify or overspecify the number of bits in the predicate?
>
> ie to deliberately have a FP vector of length 11 and a mask of length 9 or
> 13?
>
> You are referring to the sub-vector sizes, if i am understanding
> correctly. I'd assume that the mask sub-vector length always has to be
> either 1 or the same as the data sub-vector length.
>
I think that allowing the mask sub-vector length to be any divisor of the
data sub-vector length will allow the most flexible instructions, enabling
scalable vectors to be emulated by fixed-length simd operations more
easily, simplifying frontends. I don't think non-divisible lengths should
be allowed.

> For example, this is ok:
>
>    %result = call <scalable 3 x float> @llvm.evl.fsub.v4f32(<scalable 3 x
> float> %x, <scalable 3 x float> %y, <scalable 1 x i1> %M, i32 %L)
>
>    %result = call <scalable 5 x float> @llvm.evl.fsub.v4f32(<scalable 5 x
> float> %x, <scalable 5 x float> %y, <scalable 1 x i1> %M, i32 %L)
>
>    %result = call <16 x float> @llvm.evl.fsub.v4f32(<16 x float> %x, <4 x
> float> %y, <4 x i1> %M, i32 %L)
>
> This is invalid IR:
>
>    %result = call <scalable 4 x float> @llvm.evl.fsub.v4f32(<scalable 4 x
> float> %x, <scalable 4 x float> %y, <scalable 2 x i1> %M, i32 %L)
>
>    %result = call <scalable 11 x float> @llvm.evl.fsub.v4f32(<scalable 11
> x float> %x, <scalable 11 x float> %y, <scalable 9 x i1> %M, i32 %L)
>
>    %result = call <5 x float> @llvm.evl.fsub.v4f32(<5 x float> %x, <5 x
> float> %y, <7 x i1> %M, i32 %L)
>
>
> In case you are talking about the dynamic vector length (eg what happens
> if the dynamic length's don't match at runtime), i think the key here is to
> regard the vector length parameter "vlen %L" as a contract: the semantics
> of the EVL operation is undefined if the runtime lengths of the vectors are
> shorter than indicated by %L. That is the mask has a minimum element count
> of %L * mask sub-vector length, the data has a minimum element count of %L
> * data sub-vector length.
>
> - Simon
>
>
> Or, is that just a runtime error.
>
> L.
>
>
> --
> ---
> crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
>
> --
>
> Simon Moll
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190204/19a01380/attachment.html>


More information about the llvm-dev mailing list