<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-GB link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>Hi Renato, Nadav,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>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.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Please take a look and let me know what you think.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Cheers,<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>James<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>[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.<o:p></o:p></p></div></body></html>