<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 22, 2013 at 2:53 PM, Kaelyn Uhrain <span dir="ltr"><<a href="mailto:rikka@google.com" target="_blank" class="cremed">rikka@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">My $0.02 having just read the recent discussion: particularly if/when -fprofile-use=filename is smart enough to detect the type of profile, instead of having -f*-profile options like -fsample-profile, perhaps -fprofile-type=<kind> (e.g. -fprofile-type=sample, -fprofile-type=gcc, etc--or -fprofile-kind=<kind> instead of -fprofile-type) where the type defaults to GCC style... or later to whatever -fprofile-use= guesses the file's format to be. It also gives pretty good symmetry to -fprofile-generate= and -fprofile-use=</blockquote>
</div><br>Well, note that it is unlikely we'll ever default to the GCC style as that would imply reading GCC's profiles...</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm not completely opposed to this, but I'll point out two reasons why I'm not completely happy about this:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- I would personally prefer the intent to be explicit. The more I think about it the less I like one flag activating N different kinds of PGO based on the file type. It makes it too easy to typo a filename and get different (unexpected) behavior.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">- I dislike having flag A which changes flag B's behavior where possible to avoid. It makes it much harder to manipulate things through append-based build systems' flag management.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">But I wouldn't hold it up if this is the approach favored by the rest of folks discussing this. Just my 2 cents.</div></div>