[llvm-dev] bugpoint, LLVM tools (opt, llc, etc), and symbolizing costs

[David Blaikie via llvm-dev]

On Tue, May 23, 2017 at 2:40 PM Reid Kleckner <rnk at google.com> wrote:

> We have the LLVM_DISABLE_CRASH_REPORT environment variable, but that's
> more about whether we should do crash reporting or not.
>
> 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.
>

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?


>
> On Tue, May 23, 2017 at 2:02 PM, David Blaikie via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
>> test/BugPoint/metadata.ll
>> Takes about 6 seconds to run if llvm-symbolizer isn't present
>> 13 seconds with debug info
>> 1m30s with split DWARF/Fission
>>
>> So, couple of things:
>> 1) llvm-symbolizer is /really slow/ on split-dwarf files...
>> 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)?
>>
>> 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?
>>
>> Would it be worth adding such a flag and passing it from bugpoint to the
>> various tools it invokes?
>>
>> (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)
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170524/028977bf/attachment.html>