<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 03/05/2015 08:29 AM, Bob Wilson
wrote:<br>
</div>
<blockquote
cite="mid:AC046380-247D-4AFA-8375-C59158D70083@apple.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<br class="">
<div>
<blockquote type="cite" class="">
<div class="">On Mar 2, 2015, at 4:19 PM, Diego Novillo <<a
moz-do-not-send="true" href="mailto:dnovillo@google.com"
class="">dnovillo@google.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Thu, Feb 26, 2015 at 6:54
PM, Diego Novillo <span dir="ltr" class=""><<a
moz-do-not-send="true"
href="mailto:dnovillo@google.com" target="_blank"
class="cremed">dnovillo@google.com</a>></span>
wrote:</div>
<div class="gmail_quote"><br class="">
<blockquote class="gmail_quote" style="margin:0px 0px
0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr" class="">
<div class="">I've created a few bugzilla issues
with details of some of the things I'll be
looking into. I'm not yet done wordsmithing the
overall design document. I'll try to finish it
by early next week at the latest.</div>
</div>
</blockquote>
<div class=""><br class="">
</div>
<div class="">The document is available at</div>
<div class=""><br class="">
</div>
<div class=""><a moz-do-not-send="true"
href="https://docs.google.com/document/d/15VNiD-TmHqqao_8P-ArIsWj1KdtU-ElLFaYPmZdrDMI/edit?usp=sharing"
class="cremed">https://docs.google.com/document/d/15VNiD-TmHqqao_8P-ArIsWj1KdtU-ElLFaYPmZdrDMI/edit?usp=sharing </a></div>
<div class=""><br class="">
</div>
<div class="">There are several topics covered.
Ideally, I would prefer that we discuss each topic
separately. The main ones I will start working on
are the ones described in the bugzilla links we have
in the doc.</div>
<div class=""><br class="">
</div>
<div class="">This is just a starting point for us. I
am not at all concerned with implementing exactly
what is proposed in the document. In fact, if we can
get the same value using the existing support, all
the better.</div>
<div class=""><br class="">
</div>
<div class="">OTOH, any other ideas that folks may
have that work better than this are more than
welcome. I don't have really strong opinions on the
matter. I am fine with whatever works.</div>
</div>
</div>
</div>
</div>
</blockquote>
<br class="">
</div>
<div>Thanks for the detailed write-up on this. Some of the issues
definitely need to be addressed. I am concerned, though, that
some of the ideas may be leading toward a scenario where we have
essentially two completely different ways of representing
profile information in LLVM IR. It is great to have two
complementary approaches to collecting profile data, but two
representations in the IR would not make sense.</div>
<div><br class="">
</div>
<div>The first issue raised is that profile execution counts are
not represented in the IR. This was a very intentional decision.
I know it goes against what other compilers have done in the
past. It took me a while to get used to the idea when Andy first
suggested it, so I know it seems awkward at first. The advantage
is that branch probabilities are much easier to keep updated in
the face of compiler transformations, compared to execution
counts. We are definitely missing the per-function execution
counts that are needed to be able to compare relative “hotness”
across functions, and I think that would be a good place to
start making improvements. In the long term, we should keep our
options open to making major changes, but before we go there, we
should try to make incremental improvements to fix the existing
infrastructure.</div>
<div><br class="">
</div>
<div>Many of the other issues you raise seem like they could also
be addressed without major changes to the existing
infrastructure. Let’s try to fix those first.</div>
</blockquote>
After reading the document, I agree with Bob's perspective here. <br>
<br>
I would strongly recommend that you start with the optimizations
than can be implemented within the current framework. The current
infrastructure gives a fairly reasonable idea of relative hotness
within a function. There's a lot to be done to exploit that
information (even in the inliner!) without resorting to cross
function analysis. If, after most of those have been implemented,
we need more fundamental changes we could consider them. Starting
with a fundamental rewrite of the profiling system within LLVM seems
like a mistake. <br>
<br>
At a meta level, as someone who uses LLVM for JITing I would be
opposed to a system that assumed consistent profiling counts across
function boundaries and gave up on relative hotness information. At
least if I'm understanding your proposal, this would *completely
break* a multi-tiered JIT. In practice, you generally stop
collecting instrumentation profiling once something is compiled at a
high enough tier. When compiling it's caller, you'll get very
deceptive results if you rely on the execution counts to line up
across functions. On the other hand, merging two relative hotness
profiles by scaling based on the hotness of the callsite works out
quite well in practice. You can use some information about global
hotness to make decisions, but those decisions need to be resilient
to such systematic under-counting.<br>
<br>
Philip<br>
</body>
</html>