<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Apr 16, 2014, at 2:35 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 2:15 PM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.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="adM"><div class=""><div><div>On Apr 16, 2014, at 2:01 PM, Chandler Carruth <<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>> wrote:</div>
<br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 16, 2014 at 10:48 AM, Bob Wilson <span dir="ltr"><<a href="mailto:bob.wilson@apple.com" target="_blank">bob.wilson@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We need to settle of a file format ASAP for our internal work, but from the perspective of the LLVM community, it makes sense to me that this should remain wide open to change, at least until it goes out in an open-source LLVM release.</blockquote>
</div><br>Ok, I don't really know how to reconcile this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Is it fine to make breaking, backwards incompatible changes to the file format in the coming months or not?</div>
</div>
</blockquote></div><br></div></div><div>I would really like it if we can avoid making those kinds of changes, but I don’t know how to justify that from an open-source LLVM project perspective.</div><div><br></div><div>I can’t expect you to care about Apple’s release schedules but neither can I change them. It would be nice if the open-source version of LLVM can work with the PGO profile data used by Apple (especially because it seems that you guys are taking a totally different approach to PGO which won’t even use these same files).</div>
</blockquote><div><br></div><div>See, I think this is backwards. I think it would be nice if Apple could use the open source version of LLVM's profile data. But the priority for LLVM is getting this *right*.</div><div>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div> If we can get a “good enough” solution into trunk now, and if we can continue to provide support for that format, then we can make that work. If you really think it’s important to continue iterating on the file format, without adding support for reading the earlier format, then we’ll lose that. It would be unfortunate for the community IMO, but you may not agree.</div>
</blockquote></div></div><br><div>I think maintaining support for a legacy format that has never even been part of an open source LLVM release is a really lame burden to place on the community. It'll add complexity to Clang and the profile data tools. But there are many things that make pragmatic sense even though they are lame.</div>
<div><br></div><div>However, I think even worrying about this is getting in the way of developing an actual *good* file format. I think that the design discussion, iteration, and evaluation should proceed regardless of what you happen to do at Apple. </div></div></blockquote><div><br></div>I agree the top priority should always be "getting it right”. But I can’t agree with this thinking completely. This has to be balanced with pragmatism. If we completely disregard the practical concerns of commercial use, it makes LLVM hostile towards an important group of users.<br><br>Evan<br><br><blockquote type="cite"><div dir="ltr"><div>Later on, when if you end up needing to add reading support for some fixed "external" format we don't control, propose that as a separate patch that clearly factors all of the logic away into detection and reading of an alternative file format. That way its clear which is the supported and recommended format and design for the open source tools, and which is just a compatibility layer for some existing files and tools that can't be changed.</div></div></blockquote></div><div><blockquote type="cite"><div dir="ltr"><div><br><span style="color: rgb(0, 0, 0); display: inline"></span><span style="color: rgb(0, 0, 0); display: inline"></span></div><div>For example, this is how I plan to suggest teaching the llvm-profdata tool to read and merge profile data produced by profiling tools outside of LLVM like the Linux perf events, etc. It's going to come after we essentially have the pipeline well designed and worked out, as a clearly separated layer that just adds compatibility with specific fixed file formats we can't easily control.</div>
</div>
_______________________________________________<br>LLVM Developers mailing list<br><a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu">http://llvm.cs.uiuc.edu</a><br><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br></blockquote></div><br></body></html>