RFC: Enable vectorization of call instructions in the loop vectorizer

[James Molloy]

Hi Renato, Nadav,

 

Attached is a proof of concept[1] patch for adding the ability to vectorize
calls. The intended use case for this is in domain specific languages such
as OpenCL where tuned implementation of functions for differing vector
widths exist and can be guaranteed to be semantically the same as the scalar
version.

 

I've considered two approaches to this. The first was to create a set of
hooks that allow the LoopVectorizer to interrogate its client as to whether
calls are vectorizable and if so, how. Renato argued that this was
suboptimal as it required a client to invoke the LoopVectorizer manually and
couldn't be tested through opt. I agree.

 

So the version attached reads metadata attached to CallInsts. The schema for
the metadata is detailed in the proposed LangRef addition, but basically it
describes a list of potential vectorization candidates. Each candidate has a
vector width, a llvm::Function* (or MDString) giving the target function and
a string describing how the function arguments need to be handled.

 

The mangled function arguments string allows us to handle vectorizations
beyond just the pure "vectorize every argument" scenario. Consider for
example the statement "a = clamp(b, 2.0f);". OpenCL provides two forms of
"clamp2" - one with the second argument a vector and one with the second
argument a scalar. It is quite possible that the scalar form is more
optimal, and should be selected if the second argument is uniform.

 

The mangled function arguments string encodes whether each parameter expects
a vector or a scalar value. If it expects a scalar value, the vectorization
candidate will only be chosen if the argument to that parameter is uniform.

 

Please take a look and let me know what you think.

 

Cheers,

 

James

 

[1] This is very preliminary, aimed at giving reviewers something to throw
stones at. I'm aware that some code isn't defensive enough, that I've missed
several things (like making new declarations have the same attributes as old
declarations, checking for varargs.) and that there aren't enough test
cases.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131216/4fc3e44c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lv-funcalls.diff
Type: application/octet-stream
Size: 21988 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131216/4fc3e44c/attachment.obj>