[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