[llvm-dev] RFC: Interface user provided vector functions with the vectorizer.

[Doerfert, Johannes via llvm-dev]

I mean, the FE will create only one of the 3 vector versions matching the one we want for a given vector length, wouldn't it? The question now is: can we with the scalar and one vector version correctly vectorize the call. If the answer is no, what is the minimal amount of information, in addition to the two version, we would need?

Get Outlook for Android<https://aka.ms/ghei36>

________________________________
From: Francesco Petrogalli <Francesco.Petrogalli at arm.com>
Sent: Monday, June 24, 2019 6:06:12 PM
To: Tian, Xinmin
Cc: Doerfert, Johannes; Saito, Hideki; Simon Moll; LLVM Development List; Clang Dev; Renato Golin; Finkel, Hal J.; Andrea Bocci; Elovikov, Andrei; Alexey Bataev; nd; Roman Lebedev; Philip Reames; Shawn Landden
Subject: Re: RFC: Interface user provided vector functions with the vectorizer.



> On Jun 24, 2019, at 10:53 AM, Tian, Xinmin <xinmin.tian at intel.com> wrote:
>
> To me, it is also an issue related to SIMD signature matching when the vectorizer kicks in. Losing info from FE to BE is not good in general.
>

Yes, we cannot loose such information. In particular, the three examples I reported are all generating i64 in the scalar function signature:

// Type 1
typedef _Complex int S;

// Type 2
typedef struct x{
int a;
int b;
} S;

// Type 3
typedef uint64_t S;

S foo(S a, S b) {
return ...;
}


On AArch64, the correspondent vector function signature in the three cases would be (for 2-lane unmasked vectorization):

// Type 1:

<4 x int> vectorized_foo(<4 x int>, <4 x int>)

// Type 2:

%a = type struct {I 32, i32}

<2 x %a* > vectorized_foo(<2 x %a*> , <2 x %a*>)

// Type 3:

<2 x i64> vectorized_foo(<2 x i64>, <2 x i64)

To make sure that the vectorizer knows how to map the scalar function parameters to the vector ones, we have to make sure that the original signature  information is stored somewhere.

I will work on this, and provide examples.

Suggestions are welcome.

Thank you

Francesco
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190624/6398f837/attachment.html>