<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 4, 2016 at 8:32 AM, Xinliang David Li <span dir="ltr"><<a href="mailto:davidxl@google.com" target="_blank">davidxl@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Sat, Jun 4, 2016 at 1:29 AM, 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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Jun 3, 2016 at 9:47 PM, Xinliang David Li via llvm-commits <span dir="ltr"><<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span>On Fri, Jun 3, 2016 at 9:37 PM, Matthias Braun <span dir="ltr"><<a href="mailto:matze@braunis.de" target="_blank">matze@braunis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Jun 3, 2016, at 9:34 PM, Xinliang David Li via llvm-commits <<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a>> wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jun 3, 2016 at 9:32 PM, Matthias Braun<span> </span><span dir="ltr"><<a href="mailto:matze@braunis.de" target="_blank">matze@braunis.de</a>></span><span> </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">MatzeB added a comment.<br><span><br>In<span> </span><a href="http://reviews.llvm.org/D20993#449116" rel="noreferrer" target="_blank">http://reviews.llvm.org/D20993#449116</a>, @vsk wrote:<br><br>> In<span> </span><a href="http://reviews.llvm.org/D20993#449092" rel="noreferrer" target="_blank">http://reviews.llvm.org/D20993#449092</a>, @MatzeB wrote:<br>><br>> > This adds a bigger bunch of code to lit, I wonder if it is necessary:<br>> ><br>> > - I assume the necessity for the logic inside lit is just the fact that the profile data overwrites each other after running a command. Is setting LLVM_PROFILE_FILE with a '%p' placeholder not enough to avoid this?<br>><br>><br>> Using PID substitution gets close to solving the problem of having overwritten profiles, but not all the way. On 32-bit systems PID wraparound would pose a real problem. In this patch I include the hash of the test command to minimize loss of profiles.<br><br><br></span>This is a really annoying problem to have... Maybe we should find a solution within the profile infrastructure itself (can we add another flag that adds a unique suffix to the filename if it already exists?) so not every user of the profiling infrastructure has to jump through the same hoops (I've done a similar dance in the test-suite profile support).<br><span><br>><br><br>><br><br>> > The final profile data merging can always be done outside of llvm-lit afterwards.<br><br>><br><br>><br><br>> On a practical level, I don't think this is possible. Raw profiles are too large. Turning off the cleanup step and running check-llvm produces over half a terrabyte of data. There are a few ways to address this without touching lit:<br><br>><br><br>> 1. Reduce the size of raw profiles. This would make the compiler runtime larger and more complex.<br><br>> 2. Run a monitor process that does the merging/cleanup. I don't think that approach has any advantages compared to modifying lit.<br><br>><br><br>>   Alternatively, we could do in-place raw profile merging in the compiler runtime. I don't think that's preferable because we'd have to introduce a lot of complexity to compiler-rt (e.g portable mandatory file locking).<br><br><br></span>Ah, so that seems harder to solve without an external driver merging the profile data. I'm still not a big fan of injecting this stuff into the core of lit, but we may have no other choice today.<br></blockquote><div><br></div><div>This is handled by the compiler-rt -- it should be totally transparent to the user.</div></div></div></div></div></blockquote><div><br></div></div></span>That would indeed be a big usability improvement. Does it also free you from running an extra tool afterwards to convert from .profraw to .profdata format?</div></blockquote><div><br></div></span><div>The merging is only for raw format profiles which will be  super fast.   The conversion from raw to index format is still needed -- but the overhead of that is very low because thousands of raw profiles have already being reduced to a single raw file (per-executable).   </div><div><br></div><div>If we really want to simplify the use model, the compiler can be taught to recognize raw profile (and convert it to indexed format on the fly) without user knowing yet. I am yet to see a good justification for this support.</div></div></div></div></blockquote><div><br></div></span><div>It also sounds like it would have a scaling problem. It would lead to O(profile size) work done by each compiler invocation, instead of O(data needed by the compiler). Since O(profile size) is generally O(number compiler invocations), this would be quadratic in the project size.</div></div></div></div></blockquote><div><br></div></span><div>yes. The implementation can however 'cache' the indexed profile data in a file that is discoverable by later compiler invocations The file should contain info of the raw profile data's signature.  If the cached file is found and matches the raw data, it will be used instead.</div></div></div></div></blockquote><div><br></div><div>My experience when working on Clang's C++ modules for PS4 is that this kind of automatic "caching" by the compiler is of limited applicability. It:</div><div>- makes the compiler invocations non-functional (i.e. non-pure)</div><div>- serializes the build behind the back of the build system and contrary to user expectations</div><div>- circumvents the build system's dependency management; "make clean" will not work as expected</div><div>- the compiler has to start having a policy about cache expiration / pruning otherwise user's disk will fill up with files</div><div>- compiler invocations need to be assumed to have a shared file system (otherwise the "cache" is pointless and quadratic behavior remains)</div><div>- subject to these limitations, there is a large documentation burden for explaining the limitations to users the feature, thus negating much of the simplicity it is supposed to provide.</div><div><br></div><div>So I have to agree with your statement that "I am yet to see a good justification for this support". Perhaps my experiences bias me towards being extra cautious about adding a feature like this.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><font color="#888888"><div><br></div><div>David</div></font></span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><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-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><span><font color="#888888"><div><br></div><div>- Matthias</div></font></span></div></blockquote></div><br></div></div>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@lists.llvm.org" target="_blank">llvm-commits@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div></div>
</blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>