<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 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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Consolas",serif;}
span.EmailStyle23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
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-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">It might also make sense to have functions that return costs for vector ops return some sort of `LinearPolyBase` with `ScalarTy` being `InstructionCost`.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> llvm-dev <llvm-dev-bounces@lists.llvm.org> <b>On Behalf Of
</b>Vineet Kumar via llvm-dev<br>
<b>Sent:</b> Monday, November 16, 2020 11:24 PM<br>
<b>To:</b> David Sherwood <David.Sherwood@arm.com>; llvm-dev@lists.llvm.org<br>
<b>Subject:</b> [EXT] Re: [llvm-dev] [Proposal] Introducing the concept of invalid costs to the IR cost model<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p>Hi David,<o:p></o:p></p>
<p>This would be a very useful upgrade to the cost model. <o:p></o:p></p>
<p>One thing I want to add is that we need to be mindful of the cases where the cost is proportional (or inversely proportional) to the VF, for instance in the
<tt><span style="font-size:10.0pt">LoopVectorizationCostModel::selectVectorizationFactor(ElementCount MaxVF)</span></tt>, there is a point where expected cost is divided by the VF. I believe there are other places where the instruction cost is dependent on
the actual number of elements in the vector. While this is not a problem for fixed vectors, for scalable vectors we need to account for the
<tt><span style="font-size:10.0pt">vscale</span></tt> component of the VF. I guess using the polynomial type for the base cost type might work.<o:p></o:p></p>
<p>Also, for scalable vectors, when making the cost based decision of whether to vectorize or not, we will need to consider the special case of comparing the scalable vectorization cost with the scalar loop cost, which is considered to be a fixed vector cost
of VF=1. A simple solution might be to always assume that for scalable vectors, vectorization is always beneficial. Another option might be to assume that the
<tt><span style="font-size:10.0pt">vscale</span></tt> value is always at least 2, and compare the cost with the scalar loop based on that.
<o:p></o:p></p>
<p>Thanks and Regards,<o:p></o:p></p>
<p>Vineet<o:p></o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">On 2020-11-05 9:12 p.m., David Sherwood via llvm-dev wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">I'd like to propose a change to our cost interfaces so that instead of returning<o:p></o:p></p>
<p class="MsoNormal">an unsigned value from functions like getInstructionCost, getUserCost, etc., we<o:p></o:p></p>
<p class="MsoNormal">instead return a wrapper class that encodes an integer cost along with extra<o:p></o:p></p>
<p class="MsoNormal">state. The extra state can be used to express:<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">1. A cost as infinitely expensive in order to prevent certain optimisations<o:p></o:p></p>
<p class="MsoNormal">taking place. For example, there are already examples in LLVM where the cost is<o:p></o:p></p>
<p class="MsoNormal">set extremely high, but not so high that it would cause overflow. This might be to<o:p></o:p></p>
<p class="MsoNormal">prevent vectorisation in cases where we would have to scalarize the operation,<o:p></o:p></p>
<p class="MsoNormal">which is particularly relevant for scalable vectors, where scalarisation is<o:p></o:p></p>
<p class="MsoNormal">not [yet] available. There isn't currently a standard value for something that<o:p></o:p></p>
<p class="MsoNormal">constitutes very expensive and we can replace all the magic numbers with a<o:p></o:p></p>
<p class="MsoNormal">single invalid state.<o:p></o:p></p>
<p class="MsoNormal">2. A cost as unknown, where the user is simply unable to determine an accurate<o:p></o:p></p>
<p class="MsoNormal">cost for an operation.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">This new wrapper class would work almost seamlessly with existing code as it<o:p></o:p></p>
<p class="MsoNormal">would contain the full set of operators required for arithmetic and comparisons.<o:p></o:p></p>
<p class="MsoNormal">This is in addition to the ability to create invalid costs and query the validity<o:p></o:p></p>
<p class="MsoNormal">of an existing cost. Once a cost becomes invalid or unknown it will remain in that<o:p></o:p></p>
<p class="MsoNormal">state regardless of any further arithmetic performed.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal">Kind Regards,<o:p></o:p></p>
<p class="MsoNormal">David Sherwood.<o:p></o:p></p>
<p class="MsoNormal"> <o:p></o:p></p>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>LLVM Developers mailing list<o:p></o:p></pre>
<pre><a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><o:p></o:p></pre>
<pre><a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><o:p></o:p></pre>
</blockquote>
<p class="MsoNormal"><br>
<br>
WARNING / LEGAL TEXT: This message is intended only for the use of the individual or entity to which it is addressed and may contain information which is privileged, confidential, proprietary, or exempt from disclosure under applicable law. If you are not the
intended recipient or the person responsible for delivering the message to the intended recipient, you are strictly prohibited from disclosing, distributing, copying, or in any way using this message. If you have received this communication in error, please
notify the sender and destroy and delete any copies you may have received. <br>
<br>
<a href="http://www.bsc.es/disclaimer">http://www.bsc.es/disclaimer</a> <o:p></o:p></p>
</div>
</body>
</html>