<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Sep 6, 2013 at 6:00 AM, Diego Novillo <span dir="ltr"><<a href="mailto:dnovillo@google.com" target="_blank" class="cremed">dnovillo@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":16s" style="overflow:hidden">Is my understanding more or less correct?</div></blockquote><div><br></div><div>
Probably for all I know. I'm not aware of anyone actively maintaining or keeping these pieces working. AFAICT, there have been 3-4 projects that started hacking on this and didn't finish, and frankly the result is a mess. It's not clear than any of it really works today.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":16s" style="overflow:hidden"> If so, I would like to<br>
make three main changes:<br>
<br>
1- Unify profile loading so that it only talks to the basic<br>
analysis API. Here, I would like to change the way that<br>
profile information is reflected in the program. Currently,<br>
the compiler loads data from the profile file into 4 arrays<br>
inside ProfileInfo. This is then reflected into the CFG for<br>
the corresponding function.<br>
<br>
Instead, I would like to reflect profile info as metadata in<br>
the IR. For instance, functions seldom called in the profile<br>
could be annotated with the 'cold' attribute in the IR. Block<br>
frequency is more straightforward: we add the frequency data<br>
to the first instruction of the block.<br>
<br>
Things like that. The problem here is that different profiling<br>
mechanisms will have different kinds of data. We will need<br>
ways of translating those into metadata that is then served<br>
from the analysis API. For example, how do we deal with value<br>
profilers?<br>
<br>
For now, I'm focusing on the most common types of profilers.<br>
These tend to use block/edge frequencies, which are more<br>
straightforward to convert.<br></div></blockquote><div><br></div><div>I really think you should ignore the existing profile support in LLVM. ALl of it. I actually think we should remove all of it, but that can happen later.</div>
<div><br></div><div>I would build whatever passes and infrastructure you need in order to load your profile data, in whatever format makes sense, and annotate the IR with metadata. I would just build them from scratch. I don't think there is anything to be gained from trying toclean up the existing profiling infrastructure when you'll end up re-using almost none of it, you will have different constraints when dealing with profiles from sampling tools, and will still have a common IR-level interface in the metadata.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":16s" style="overflow:hidden">
<br>
2- Passes should not need to be aware that profile<br>
information exists. They would make the usual calls to the<br>
analysis API, which will use profile data, if available.<br>
<br>
With this, I want to make optimizers automatically make<br>
better decisions when profile information exists.<br></div></blockquote><div><br></div><div>I believe this has already been done. I'm not aware of any optimization passes in use today that will need changes here.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":16s" style="overflow:hidden">
<br>
3- Profile data should be flexible wrt code drift. This is<br>
something that the profile loader should deal with. It<br>
currently fails when the profile is out of sync with the shape<br>
of the IR. In the presence of stale profile:<br>
(a) Do not fail hard.<br>
(b) Make conservative decisions with the annotations it<br>
generates.<br>
(c) Provide feedback to the user about the staleness of the<br>
profile (e.g. % of samples/records dropped from the profile).<br></div></blockquote></div><br>Yes, in designing your own (from the ground up) loader, these will be important issues.</div></div>