[PATCH] D40917: Emit .debug$H section in clang

[David Blaikie via llvm-commits]

On Mon, Dec 11, 2017 at 12:18 PM Zachary Turner <zturner at google.com> wrote:

> Tge followup patch actually gives some benchmarks, and i have a document
> that I’m writing up in parallel that details some of this. But tl;dr is
> about 35-40% reduction in link time.
>
> Also, the followup patch (which adds support to lld) does contain more end
> to end tests, but i wanted to split up the work
>

*nod* Will the user still have to pass the linker flag after that patch? If
so it'd still seem to me to make sense to opt in in both cases, rather than
have the size penalty opt-out and the linker-speed opt-in.

(or ideally one flag, that you can add to your compiler flags - that causes
both linker and compiler to do the right things - assuming you're using the
compiler as your linker driver)


> On Mon, Dec 11, 2017 at 11:59 AM David Blaikie <dblaikie at gmail.com> wrote:
>
>> 15% increase in object size is pretty huge (at least in the world I'm
>> working in, which is admittedly rather different than yours). By untested I
>> meant end-to-end, sorry, should've been clear. Like "not
>> demonstrated/used/useful" (for someone who uses the compiler today).
>>
>> On Mon, Dec 11, 2017 at 10:43 AM Zachary Turner <zturner at google.com>
>> wrote:
>>
>>> I think there is a decent amount of test coverage provided by this and
>>> previous patches.  Was there some other kind of test coverage you had in
>>> mind?  I toyed with the idea of putting it behind an option, but it seemed
>>> unnecessary since there is no real disadvantage to having the extra data in
>>> there, aside from a relatively small increase in build size.
>>>
>>> On Mon, Dec 11, 2017 at 10:37 AM David Blaikie <dblaikie at gmail.com>
>>> wrote:
>>>
>>>> Seems a bit surprising to me to implement this as on by default while
>>>> it's unused and untested - I'd expect an extra flag during such an
>>>> experimental phase?
>>>>
>>>> On Wed, Dec 6, 2017 at 12:59 PM Zachary Turner via Phabricator via
>>>> llvm-commits <llvm-commits at lists.llvm.org> wrote:
>>>>
>>>>> zturner created this revision.
>>>>> Herald added subscribers: JDevlieghere, hiraditya, mgorny.
>>>>>
>>>>> This causes emission of .debug$H section unconditionally when
>>>>> `-gcodeview` is present.
>>>>>
>>>>> I ran some benchmarks on a self-hosted build and found a ~2% increase
>>>>> in overall build time (within the margin of error, so basically noise), and
>>>>> a ~15% increase in object file size, on average.
>>>>>
>>>>> Currently the linker doesn't use this, that will work will come in a
>>>>> followup patch.  For now, we're just testing that clang emits it correctly
>>>>> with some obj2yaml and llc based tests.
>>>>>
>>>>>
>>>>> https://reviews.llvm.org/D40917
>>>>>
>>>>> Files:
>>>>>   llvm/include/llvm/DebugInfo/CodeView/GlobalTypeTableBuilder.h
>>>>>   llvm/include/llvm/DebugInfo/CodeView/TypeHashing.h
>>>>>   llvm/include/llvm/MC/MCObjectFileInfo.h
>>>>>   llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.cpp
>>>>>   llvm/lib/CodeGen/AsmPrinter/CodeViewDebug.h
>>>>>   llvm/lib/DebugInfo/CodeView/CMakeLists.txt
>>>>>   llvm/lib/DebugInfo/CodeView/GlobalTypeTableBuilder.cpp
>>>>>   llvm/lib/MC/MCObjectFileInfo.cpp
>>>>>   llvm/lib/ObjectYAML/CodeViewYAMLTypeHashing.cpp
>>>>>   llvm/test/DebugInfo/COFF/global-type-hashes.ll
>>>>>   llvm/test/DebugInfo/COFF/globals.ll
>>>>>
>>>>> _______________________________________________
>>>>> llvm-commits mailing list
>>>>> llvm-commits at lists.llvm.org
>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>>>>>
>>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20171211/12e875e8/attachment.html>