[llvm-dev] [RFC] Vector Predication

Simon Moll via llvm-dev llvm-dev at lists.llvm.org
Mon Feb 4 12:13:57 PST 2019


On 2/4/19 6:15 PM, David Greene wrote:
> Simon Moll <moll at cs.uni-saarland.de> writes:
>
>> 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. 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)
> What does <scalable 1 x i1> applied to <scalable 3 x float> mean?  I
> would expect a requirement of <scalable 3 x i1>.  At least that's how I
> understood the SVE proposal [1].  The n's in <scalable n x type> have to
> match.

It would mean that the each mask bit M[i] applies to data lanes D[3*i] to D[3*i+2]. It has applications in graphics codes where the vector element type would be a short vector as in [2]:

for(int i = 0; i < 1000; i++)
{
     vec4 color = colors[i];    // <scalable 4 x float>
     vec3 normal = normals[i];  // <scalable 3 x float>
     color.rgb *= fmax(0.0, dot(normal, light_dir));
     colors[i] = color;
}



I don't see any direct conflict with LLVM-SVE [1] but it will add complexity to the vectorizer, legal and TTI to choose a good sub-vector size/strategy for each target.

- Simon


[2] https://lists.llvm.org/pipermail/llvm-dev/2019-January/129822.html

>
>                             -David
>
> [1] http://lists.llvm.org/pipermail/llvm-dev/2016-November/106819.html

-- 

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/41fd2a4a/attachment.html>


More information about the llvm-dev mailing list