<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 4, 2015 at 7:50 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><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">silvas added a subscriber: silvas.<br>
silvas added a comment.<br>
<br>
I would prefer not to silently break compatibility. These things tend to come back and bite. In particular, `static` functions are quite common, and we are unlikely to "do the right thing" with just this patch (actually, I know that this will affect the intrinsics in our built-in headers, so most code is likely to be affected). Do we have a versioning mechanism available so that we can produce a proper diagnostic and reject the file?<br>
<br></blockquote><div><br></div><div>For this particular case, there is actually a way to make the change backward compatible.</div><div> </div><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">
Personally, I am not strongly opposed to changing the format. We are still rolling out PGO to our customers and haven't produced explicit documentation on this aspect, but my intention is that we will document to our users that we do not guarantee any compatibility of the profraw or profdata files across releases. </blockquote><div><br></div><div><br></div><div>My understanding is that we don't promise profraw compatibility across releases.  It makes sense to keep the compatibility for indexed format -- we even have regression test to guarantee v1 format still works.  In fact, we now have mechanism set up such that making compatible changes for indexed format does not require too much effort for most of the cases.</div><div><br></div><div><br></div><div> </div><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">So in principle I have no concerns with breaking old profraw or profdata files as long as we cleanly reject them (besides a slight apprehension since I often am comparing compilers across releases and it is convenient to not have to have a separate llvm-profdata for each release).<br>
<br></blockquote><div><br></div><div>This is a valid use case -- assuming program sources don't change. If they changed, keeping old profile data do not make sense anymore.</div><div> </div><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">
So I will defer to Justin about whether we should break compatibility over this aspect and if so, how we should handle the transition.<br>
<br></blockquote><div><br></div><div>No worries -- this one can be compatible. </div><div><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div><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">
<br>
<a href="http://reviews.llvm.org/D15243" rel="noreferrer" target="_blank">http://reviews.llvm.org/D15243</a><br>
<br>
<br>
<br>
</blockquote></div><br></div></div>