<div dir="ltr">><span style="font-size:12.8px">process. I think that it could lead to exploring a better </span><span style="font-size:12.8px">representation than YAML which is, indeed, a little slow to parse</span><div><span style="font-size:12.8px"><br>As a datapoint the codebase of a recent PlayStation4 game produces over 10GiB of YAML files, of course I'm tending to run opt-viewer on just a subset of these to get a reasonable workflow.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Just looking at one of the graphics libraries, which is a reasonable granularity to examine, we have ~10MiB of object file for x86-64, including debug info. This produces ~70MiB of YAML which takes 48s to parse (optrecord.gather_results) and 25s to produce a total of ~70MiB of HTML (generate_report) on a decent i7 with SSD. Not terrible but probably too slow for our end-users.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Brian, did you get time to try out some alternative representations? Although we've not done any finer-grained profiling of the above we also suspect a binary representation might improve things. If you've not looked at this yet we might be able to investigate over the next couple of weeks. If you already have then I'd be happy to test against the codebase above and see what the difference is like.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">To echo Davide, we don't want to sound too negative - the remarks work is definitely a good direction to be going in and is already useful.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Thanks,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Simon</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 14, 2017 at 8:21 AM, Davide Italiano via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jun 19, 2017 at 4:13 PM, Brian Gesiak via llvm-dev<br>
<<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> Hello all,<br>
><br>
> In <a href="https://www.youtube.com/watch?v=qq0q1hfzidg" rel="noreferrer" target="_blank">https://www.youtube.com/watch?<wbr>v=qq0q1hfzidg</a>, Adam Nemet (cc'ed) describes<br>
> optimization remarks and some future plans for the project. I had a few<br>
> follow-up questions:<br>
><br>
> 1. As an example of future work to be done, the talk mentions expanding the<br>
> set of optimization passes that emit remarks. However, the Clang User Manual<br>
> mentions that "optimization remarks do not really make sense outside of the<br>
> major transformations (e.g.: inlining, vectorization, loop optimizations)."<br>
> [1] I am wondering: which passes exist today that are most in need of<br>
> supporting optimization remarks? Should all passes emit optimization<br>
> remarks, or are there indeed passes for which optimization remarks "do not<br>
> make sense"?<br>
><br>
> 2. I tried running llvm/utils/opt-viewer/opt-<wbr>viewer.py to produce an HTML<br>
> dashboard for the optimization remark YAML generated from a large C++<br>
> program. Unfortunately, the Python script does not finish, even after over<br>
> an hour of processing. It appears performance has been brought up before by<br>
> Bob Haarman (cc'ed), and some optimizations have been made since. [2] I<br>
> wonder if I'm passing in bad input (6,000+ YAML files -- too many?), or if<br>
> there's still some room to speed up the opt-viewer.py script? I tried the<br>
> C++ implementation as well, but that never completed either. [3]<br>
><br>
> Overall I'm excited to make greater use of optimization remarks, and to<br>
> contribute in any way I can. Please let me know if you have any thoughts on<br>
> my questions above!<br>
><br>
<br>
</div></div>Hi,<br>
I've been asked at $WORK to take a look at `-opt-remarks` , so here<br>
are a couple of thoughts.<br>
<br>
1) When LTO is on, the output isn't particularly easy to read. I guess<br>
this can be mitigated with some filtering approach, I and Simon<br>
discussed it offline.<br>
<br>
2) Yes, indeed `opt-viewer` takes forever for large testcases to<br>
process. I think that it could lead to exploring a better<br>
representation than YAML which is, indeed, a little slow to parse. To<br>
be honest, I'm torn about this.<br>
YAML is definitely really convenient as we already use it somewhere in<br>
tree, and it has an easy textual repr. OTOH, it doesn't seem to scale<br>
that nicely.<br>
<br>
3) There are lots of optimizations which are still missing from the<br>
output, in particular PGO remarks (including, e.g. branch info<br>
probabilities which still use the old API as far as I can tell<br>
[PGOInstrumentation.cpp])<br>
<br>
4) `opt-remarks` heavily relies on the fidelity of the DebugLoc<br>
attached to instructions. Things get a little hairy at -O3 (or with<br>
-flto) because there are optimizations bugs so transformations don't<br>
preserve debuginfo. This is not entirely orthogonal but something can<br>
be worked on in parallel (bonus point, this would also help SamplePGO<br>
& debuginfo experience). With `-flto` the problem gets amplified more,<br>
as expected.<br>
<br>
5) I found a couple of issue when trying the support, but I'm actively<br>
working on them.<br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=33773" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=33773</a><br>
<a href="https://bugs.llvm.org/show_bug.cgi?id=33776" rel="noreferrer" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=33776</a><br>
<br>
That said, I think optimization remarks support is coming along nicely.<br>
<br>
--<br>
Davide<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</div></div></blockquote></div><br></div>