<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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman","serif";}
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-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Hi Nadav,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Thanks for the quick reply!<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal>> I don’t like the vectorizer.call metadata because it does not solve the general problem. Yes, it will allow the vectorization of some OpenCL functions but it will not help the vectorization of other math functions in regular C loops. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The difficulty I had is how to effectively model the transforms in a way that works for OpenCL (which, I admit, is the only case I care about at the moment) but also for whatever others may reasonably want to use it for. Is your argument that the constraints on whether vectorization of general math functions is possible cannot be expressed in metadata? I’m inclined to agree, which is why I initially pushed for the querying hook mechanism.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> I think that this kind of logic should go into TargetLibraryInfo, and not as part of the vectorizers.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>This sounds similar to my original approach of adding hooks. And indeed, TargetLibraryInfo certainly sounds like the best place for them.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>> I understand this problem but I don’t want to add OpenCL-specific knowledge into the loop-vectorizer.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>I do understand your concern and I agree, but I don’t see how the solution I just proposed is OpenCL-specific… is it that the solution is just not applicable to other uses? (as mentioned in my first paragraph)<o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>> </span>One possible solution would be to work around this problem by extending your OpenCL library and by introducing OpenCL-specific passes that will detect these kind of patterns and optimize your vectorized code using the OpenCL knowledge. <o:p></o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Totally doable. I’m very keen to add the “right” support upstream – I don’t expect upstream to solve my problem completely. I’m happy to do whatever cleanup or modifications are needed downstream to keep upstream uncluttered.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>If I’ve understood you correctly (please let me know if I haven’t!) then I’ll get on creating a prototype using TLI hooks.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Cheers,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>James<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm 4.0pt'><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> Nadav Rotem [mailto:nrotem@apple.com] <br><b>Sent:</b> 16 December 2013 17:27<br><b>To:</b> James Molloy<br><b>Cc:</b> llvm-commits@cs.uiuc.edu for LLVM; Renato Golin<br><b>Subject:</b> Re: RFC: Enable vectorization of call instructions in the loop vectorizer<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hi James!<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks for working on this. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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></span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Excellent!<o:p></o:p></p></div><p class=MsoNormal><br><br><o:p></o:p></p><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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></span></p></div></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I think that this kind of logic should go into TargetLibraryInfo, and not as part of the vectorizers. The vectorizers should use some kind of API that will translate cos into cos4. I don’t like the vectorizer.call metadata because it does not solve the general problem. Yes, it will allow the vectorization of some OpenCL functions but it will not help the vectorization of other math functions in regular C loops. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'> <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif"'>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></span></p></div></div></blockquote><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>I understand this problem but I don’t want to add OpenCL-specific knowledge into the loop-vectorizer. One possible solution would be to work around this problem by extending your OpenCL library and by introducing OpenCL-specific passes that will detect these kind of patterns and optimize your vectorized code using the OpenCL knowledge. <o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>Thanks,<o:p></o:p></p></div><div><p class=MsoNormal>Nadav<o:p></o:p></p></div></div></div></div></body></html>