<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Feb 21, 2014 at 11:34 AM, Hal Finkel <span dir="ltr"><<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">----- Original Message -----<br>
> From: "Chandler Carruth" <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>><br>
> To: <a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
> Sent: Tuesday, January 22, 2013 5:26:02 AM<br>
> Subject: [llvm-commits] [llvm] r173148 - in /llvm/trunk: include/llvm/Analysis/TargetTransformInfo.h<br>
> lib/Analysis/CodeMetrics.cpp lib/Analysis/IPA/InlineCost.cpp lib/Analysis/TargetTransformInfo.cpp<br>
> lib/Transforms/Scalar/TailRecursionElimination.cpp<br>
><br>
> Author: chandlerc<br>
> Date: Tue Jan 22 05:26:02 2013<br>
> New Revision: 173148<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=173148&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=173148&view=rev</a><br>
> Log:<br>
> Begin fleshing out an interface in TTI for modelling the costs of<br>
> generic function calls and intrinsics. This is somewhat overlapping<br>
> with<br>
> an existing intrinsic cost method, but that one seems targetted at<br>
> vector intrinsics. I'll merge them or separate their names and use<br>
> cases<br>
> in a separate commit.<br>
><br>
> This sinks the test of 'callIsSmall' down into TTI where targets can<br>
> control it. The whole thing feels very hack-ish to me though. I've<br>
> left<br>
> a FIXME comment about the fundamental design problem this presents.<br>
> It<br>
> isn't yet clear to me what the users of this function *really* care<br>
> about. I'll have to do more analysis to figure that out. Putting this<br>
> here at least provides it access to proper analysis pass tools and<br>
> other<br>
> such. It also allows us to more cleanly implement the baseline cost<br>
> interfaces in TTI.<br>
><br>
> With this commit, it is now theoretically possible to simplify much<br>
> of<br>
> the inline cost analysis's handling of calls by calling through to<br>
> this<br>
> interface. That conversion will have to happen in subsequent commits<br>
> as<br>
> it requires more extensive restructuring of the inline cost analysis.<br>
><br>
> The CodeMetrics class is now really only in the business of running<br>
> over<br>
> a block of code and aggregating the metrics on that block of code,<br>
> with<br>
> the actual cost evaluation done entirely in terms of TTI.<br>
<br>
</div></div>Looking at this in detail,<br>
<br>
+    NumInsts += TTI.getUserCost(&*II);<br>
<br>
I'm not sure this is doing what we want. The issue is that the cost model is designed to be used with the vectorizer, and the 'costs' produced by that model don't really measure instructions, or even uop counts, but relative throughput. This means, for example, that if we can dispatch two integer adds per cycle, and 1 floating-point add per cycle, then the floating point add will have twice the cost of the integer add (which probably has a cost of 1). But it is not clear to me at all that this is the appropriate measure for inlining and unrolling (especially for unrolling, for OOO cores with loop dispatch buffers, we almost certainly want uop counts).<br>

<br>
So the question is: what to do about this? The straightforward thing seems to be to add some kind of 'cost-type' to all of the TTI cost APIs. There seem to be three potentially relevant kinds of costs:<br>
 - Scaled throughput<br>
 - uop counts<br>
 - instruction counts (or, perhaps instead: in-memory code size)<br>
<br>
The advantage of doing this is, for the most part, none of the target independent code would need to care about what kind of cost we needed (because the scalarization logic probably does not care), and just the target parts need to change. But maybe there is a better way. Opinions?<br>
</blockquote><div><br></div><div>So, what Arnold said, but more generally I think we should formalize this more.</div><div><br></div><div>The inliner doesn't actually *care* what is counted though. It's not clear that we actually have any users that want the third measurement. Instead, we have users that want to have an incredibly coarse corollary. As such, I would focus on better interfaces for scaled throughput and uop counts, and then we may find that one of these can easily be used by the inliner as a "good enough" approximation of code size.</div>
<div><br></div><div>To be more specific about what the inliner cares about: it doesn't really care much about the exact size, throughput, or anything else. Instead, it cares about recognizing IR patterns which literally *disappear* on the target (zext and bitcast are huge here), and IR patterns that *explode* on the target like floating point math that we have to lower to library calls. Everything else is essentially noise.<br>
</div><div><br></div><div>-Chandler.</div></div></div></div>