<div dir="ltr">So - fixed part of this in D33804/r<span style="color:rgb(33,33,33)">305056 (at least not symbolizing crashes of the 'opt' tool when run from bugpoint - I still need to generalize this over the other tools/way bugpoint runs programs & fix those too)<br><br>But realized there's another place where we're paying a lot for symbolizing and this one isn't saved by bugpoint's memory limit*: GUnit death tests.<br><br>For example ADTTests takes about 20 seconds without symbolizing, and about 1m35 with symbolizing. (though doesn't seem to have a significant impact on total runtime of "check-llvm" on my machine - probably some other longer poles propping it up)<br><br>Any idea how we can/should disable symbolizing for these tests? Wondering if we could have a scoped device to disable symbolizing around known/intended crashes/assert failures? Though would be annoying to have to have another trick to be needed in any death test - people could easily forget. :/</span><br><br>* After doing more investigation I found out why Split DWARF debug info was so much slower here than internal - bugpoint places a memory limit, including an address space limit, of 400MB on the processes it launches. llvm-symbolizer inherits this limit when symbolizing a crash. Memory mapping in a binary with non-split DWARF exceeds the limit and fails - so it's fast because it doesn't symbolize.<br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 23, 2017 at 6:38 PM David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<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_quote"><div dir="ltr">On Tue, May 23, 2017 at 2:40 PM Reid Kleckner <<a href="mailto:rnk@google.com" target="_blank">rnk@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">We have the LLVM_DISABLE_CRASH_REPORT environment variable, but that's more about whether we should do crash reporting or not.<div><br></div><div>It would be pretty reasonable to have another one to disable all this stuff. It would also be reasonable to have a cmake option that compiles this stuff away, since it basically never works on user machines that don't have debug info.</div></div></blockquote></div></div><div dir="ltr"><div class="gmail_quote"><div><br>Fair - any thoughts of having a dynamic option (rather than a build time option) so that things like bugpoint could disable it for runs of tools, but the tools itself could still have the functionality for once you finish running bugpoint and then run the same command manually?<br> </div></div></div><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_extra"><br><div class="gmail_quote"></div></div><div class="gmail_extra"><div class="gmail_quote">On Tue, May 23, 2017 at 2:02 PM, 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> wrote:<br></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">test/BugPoint/metadata.ll<br>Takes about 6 seconds to run if llvm-symbolizer isn't present<br>13 seconds with debug info<br>1m30s with split DWARF/Fission<br><br>So, couple of things:<br>1) llvm-symbolizer is /really slow/ on split-dwarf files... <br>2) Why are stack traces even attempted when using bugpoint? Even if it's just the 6->13s slowdown, that's still halving the speed of bugpoint in the presence of llvm-symbolizer+debug info (I didn't test in the presence of llvm-symbolizer but no debug info)?<br><br>It doesn't look like the LLVM tools have any way to disable symbolization/stack trace/crash handling. Is that correct? Is there a flag somewhere that I missed?<br><br>Would it be worth adding such a flag and passing it from bugpoint to the various tools it invokes?<br><br>(anyone interested in looking at exactly what makes llvm-symbolizer /so/ much slower on split DWARF? I guess that's probably something for me to look at, really (though I checked that it's at least not due to my recent changes - but there have been some other refactorings here recently too) - but figured I'd check)</div>
<br></blockquote></div></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">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/mailman/listinfo/llvm-dev</a><br>
<br></blockquote></div><br></div>
</blockquote></div></div></blockquote></div></div>