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

[Zachary Turner via llvm-commits]

After that patch, the user has to use /DEBUG:GHASH to the linker. The idea
being that later that will become always-on and no way to opt out. Ie the
only mode.

It’s hard to get benchmarks against existing applications if you have to
modify the build system to pass cc1 options through to the compiler, so
there’s some practical value in having it on by default as well
On Mon, Dec 11, 2017 at 12:21 PM David Blaikie <dblaikie at gmail.com> wrote:

> 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/71920330/attachment.html>