<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 17, 2017 at 5:18 PM, Mehdi AMINI <span dir="ltr"><<a href="mailto:joker.eph@gmail.com" target="_blank">joker.eph@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2017-07-17 16:49 GMT-07:00 David Blaikie via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span>:<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><br><div class="gmail_quote"><span class="m_8035965393391838913gmail-"><div dir="ltr">On Mon, Jul 17, 2017 at 6:11 AM Charles Saternos via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<br></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><span style="font-size:12.8px">Hey @chandlerc and @dblaikie,</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Any updates on this in relation to "</span>[PATCH] D34080: [ThinLTO] Add dump-summary command to llvm-lto2 tool"?</div></div></blockquote></span><div><br>Sorry you've kind of got stuck in the middle of this - but I'm still hoping to hear/understand the pushback on implementing this as a first class .ll construct with serialization and deserialization support.<br><br>I think Peter mentioned he didn't think this was the right path forward in the long term? If that's the case, I'd like to understand that/reach that conclusion for the project now rather than treating this as a stop-gap with some idea that in the future someone might implement full serialization support (when it's been over a year already, and other stop gaps have been implemented (the yaml input support) already).<br></div></div></div></blockquote><div><br></div></span><div>I'm totally believing we need first class serialization support in .ll, and I have a path forward for this (just not a lot of time to dedicate to this).</div><div><br></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_quote"><div><br>& if a .ll construct with serialization/deserialization is the path forward, understanding the motivation for a something other than going straight for that would be helpful -usually bitcode features come with .ll support from day 1, not a year later. I'm not clear on what would make this feature an exception/more expensive to do this for (& why it would be worth deferring that work, and what/when that work will be motivated/done)</div></div></div></blockquote><div><br></div><div><br></div><div><div>We need a debugging tool for summaries ASAP, and the YAML is *already* implemented. Making it available through the llvm-lto tool is a no-brainer to me.</div></div></div></div></div></blockquote><div><br></div><div>I will add that using Charles' patches to dump the summary with YAML was invaluable in tracking down a bug recently.  Much easier than trying to decode the llvm-bcanalyzer output. It would be great to get those in now, as Mehdi notes there is already some existing YAML summary support, and I do believe it is going to take some time to get serialization through the .ll file defined and implemented (I know I don't have bandwidth at the moment).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><div><br></div><div>This was *not* an oversight but a deliberate choice to not do this in the first place. Because summaries are the first bitcode feature I know of that isn't attached in any way to a Module (you can't get to it from a Module).</div></div></div></div></div></blockquote><div><br></div><div>And because the summaries are computed from the IR.</div><div><br></div><div>But I don't disagree that it would be good to have serialization in/out of .ll files, if only for debugging and testing purposes.</div><div><br></div><div>Teresa</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div><br></div><div>-- </div><div>Mehdi</div></font></span></div></div></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><span style="font-family:Times;font-size:medium"><table cellspacing="0" cellpadding="0"><tbody><tr style="color:rgb(85,85,85);font-family:sans-serif;font-size:small"><td nowrap style="border-top-style:solid;border-top-color:rgb(213,15,37);border-top-width:2px">Teresa Johnson |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(51,105,232);border-top-width:2px"> Software Engineer |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(0,153,57);border-top-width:2px"> <a href="mailto:tejohnson@google.com" target="_blank">tejohnson@google.com</a> |</td><td nowrap style="border-top-style:solid;border-top-color:rgb(238,178,17);border-top-width:2px"> 408-460-2413</td></tr></tbody></table></span></div>
</div></div>