<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class=""><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><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><br></div><div>thanks,</div><div><br></div><div>David</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Matthias</div></font></span></div></blockquote></div><br></div></div>