<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 10:17 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 class="im">On Tue, Oct 22, 2013 at 1:13 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" class="cremed">chandlerc@google.com</a>> wrote:<br>

<br>
> I'm surprised -- I expected this to essentially only be used with<br>
> sample-based profiles? Bob seemed to have a different architecture in mind<br>
> for other profile sources?<br>
<br>
</div>For now, sure.  But there are other profile sources that are not based<br>
on sampling.  Instrumentation being one. Value tracking, being<br>
another. AFAIR, Bob is looking at instrumentation-based approaches.<br>
<div class="im"><br>
> If this is going to be something generic, we should have some input from Bob<br>
> as well at least. And then the flag name it seems should be "-fprofile" or<br>
> "-fprofile-file" or "-fprofile-input"....<br>
<br>
</div>Sure. No qualification seems the best option here.</blockquote></div><br>I wonder if the better way to go is to start with a very narrow flag name, and generalize it when the infrastructure for more generalized profile reading arrives? Supporting a highly specific flag for a long time doesn't seem like a high cost.</div>
</div>