<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:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" 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=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Book Antiqua";
panose-1:2 4 6 2 5 3 5 3 3 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:"Book Antiqua",serif;
color:#943634;
font-weight:normal;
font-style:normal;
text-decoration:none none;}
.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-IE link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:black;mso-fareast-language:EN-US'>Our architecture has 2 different sizes for vector registers with separate register files and functional units for each, and the existing cost model already makes optimisation for this quite difficult. Ideally the loop-vectoriser would be able to vectorise for vectorisable code in the loop using both in parallel. At the moment the architectures that in the TRUNK for LLVM all use a single size for vector registers and a single register file for them, but I expect there are other out-of-tree targets that are using multiple vector register widths.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:black;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:black;mso-fareast-language:EN-US'>Removing the width limitation altogether I think would make optimisations for hybrid vector models such as ours less difficult, but it also means the cost model should be able to query for the vector width and expect to get a list instead of a single value as it does now. Querying for the number of vector registers should be a function of the vector type being examined.<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:black;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:black;mso-fareast-language:EN-US'> MartinO<o:p></o:p></span></p><p class=MsoNormal><span style='font-family:"Book Antiqua",serif;color:black;mso-fareast-language:EN-US'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span lang=EN-US style='font-size:11.0pt;font-family:"Calibri",sans-serif'> llvm-dev [mailto:llvm-dev-bounces@lists.llvm.org] <b>On Behalf Of </b>Michael Kuperstein via llvm-dev<br><b>Sent:</b> 15 June 2016 23:48<br><b>To:</b> Hal Finkel <hfinkel@anl.gov>; Nadav Rotem <nadav.rotem@me.com>; Ayal Zaks <ayal.zaks@intel.com>; Demikhovsky, Elena <elena.demikhovsky@intel.com>; Adam Nemet <anemet@apple.com>; Sanjoy Das <sanjoy@playingwithpointers.com>; James Molloy <james.molloy@arm.com>; Matthew Simpson <mssimpso@codeaurora.org>; Sanjay Patel <spatel@rotateright.com>; Chandler Carruth <chandlerc@google.com>; David Li <davidxl@google.com>; Wei Mi <wmi@google.com>; Dehao Chen <dehao@google.com>; Cong Hou <congh@google.com><br><b>Cc:</b> Llvm Dev <llvm-dev@lists.llvm.org><br><b>Subject:</b> [llvm-dev] [RFC] Allow loop vectorizer to choose vector widths that generate illegal types<o:p></o:p></span></p><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>Hello,<br><br>Currently the loop vectorizer will, by default, not consider vectorization factors that would make it generate types that do not fit into the target platform's vector registers. That is, if the widest scalar type in the scalar loop is i64, and the platform's largest vector register is 256-bit wide, we will not consider a VF above 4.<br><br>We have a command line option (-mllvm -vectorizer-maximize-bandwidth), that will choose VFs for consideration based on the narrowest scalar type instead of the widest one, but I don't believe it has been widely tested. If anyone has had an opportunity to play around with it, I'd love to hear about the results.<br><br>What I'd like to do is:<o:p></o:p></p><div><div><p class=MsoNormal>Step 1: Make -vectorizer-maximize-bandwidth the default. This should improve the performance of loops that contain mixed-width types.<br>Step 2: Remove the artificial width limitation altogether, and base the vectorization factor decision purely on the cost model. This should allow us to get rid of the interleaving code in the loop vectorizer, and get interleaving for "free" from the legalizer instead.<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>There are two potential road-blocks I see - the cost-model, and the legalizer. To make this work, we need to:<o:p></o:p></p></div><div><p class=MsoNormal>a) Model the cost of operations on illegal types better. Right now, what we get is sometimes completely ridiculous (e.g. see <a href="http://reviews.llvm.org/D21251">http://reviews.llvm.org/D21251</a>).<o:p></o:p></p></div><div><p class=MsoNormal>b) Make sure the cost model actually stops us when the VF becomes too large. This is mostly a question of correctly estimating the register pressure. In theory, that should not be a issue - we already rely on this estimate to choose the interleaving factor, so using the same logic to upper-bound the VF directly shouldn't make things worse.<o:p></o:p></p></div><div><p class=MsoNormal>c) Ensure the legalizer is up to the task of emitting good code for overly wide vectors. I've talked about this with Chandler, and his opinion (Chandler, please correct me if I'm wrong) is that on x86, the legalizer is likely to be able to handle this. This may not be true for other platforms. So, I'd like to try to make this the default on a platform-by-platform basis, starting with x86.<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>What do you think? Does this seem like a step in the right direction? Anything important I'm missing?<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> Michael<o:p></o:p></p></div></div></div></div></div></body></html>