[cfe-dev] Should dump methods be LLVM_ATTRIBUTE_USED only in debug builds?
Philip Reames
listmail at philipreames.com
Thu Jan 2 17:46:30 PST 2014
On 1/2/14 5:10 PM, Argyrios Kyrtzidis wrote:
> On Jan 2, 2014, at 4:02 PM, Nico Weber <thakis at chromium.org
> <mailto:thakis at chromium.org>> wrote:
>
>> On Thu, Jan 2, 2014 at 11:36 AM, Argyrios Kyrtzidis
>> <akyrtzi at gmail.com <mailto:akyrtzi at gmail.com>> wrote:
>>
>>
>> On Jan 2, 2014, at 11:05 AM, Nico Weber <thakis at chromium.org
>> <mailto:thakis at chromium.org>> wrote:
>>
>>> On Fri, Dec 27, 2013 at 5:01 PM, Chandler Carruth
>>> <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>>>
>>>
>>> On Fri, Dec 27, 2013 at 7:46 PM, Nico Weber
>>> <thakis at chromium.org <mailto:thakis at chromium.org>> wrote:
>>>
>>> Hi,
>>>
>>> r151033 and r151037 marked a few dump() methods
>>> as LLVM_ATTRIBUTE_USED, and over time this inspired
>>> marking several other dump() methods to be marked as
>>> such too (see e.g. 178400, 182186, 159790, 173548).
>>>
>>> I understand that having the dump() methods available in
>>> the debugger is useful, but these annotations prevent
>>> the dump() methods from being dead-stripped, and they
>>> end up keeping lots of code alive. For example,
>>> clang-format depends on ASTDumper, TypePrinter,
>>> StmtVisitor and related stuff solely for these dump methods.
>>>
>>> Since binaries now get dead-stripped, this leads to
>>> measurable bloat: clang-format goes from 1.7 MB to 1.2
>>> MB if I remove the LLVM_ATTRIBUTE_USEDs on the 17 dump
>>> methods in include/clang -- an almost 30% reduction.
>>>
>>> Does it make sense to only mark dump methods
>>> as LLVM_ATTRIBUTE_USED if !NDEBUG?
>>>
>>>
>>> I think what makes sense is to not have these methods in
>>> !NDEBUG. This is the way dump methods are being written in
>>> LLVM these days:
>>>
>>> #if !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
>>> void some_helper_function_only_used_by_dump() const;
>>> void LLVM_ATTRIBUTE_NOINLINE LLVM_ATTRIBUTE_USED dump() const;
>>> #endif
>>>
>>> At least, this is how SROA.cpp does it, and I think it has
>>> been suggested to do it consistently in this way.
>>>
>>> My preference would be to:
>>>
>>> a) Make this pattern easier to reproduce where needed.
>>> b) Try to make existing dump code use it more regularly
>>> throughout both LLVM and Clang to fix just the problem
>>> you've identified.
>>>
>>>
>>> Ah, good point bringing up dump() in llvm! Looking through ` ack
>>> -C 3 -i dump include/` in llvm, it looks like none of the dump
>>> methods in llvm are marked as LLVM_USED -- maybe it's reasonable
>>> that people who want to call this from gdb during debugging
>>> insert that locally manually?
>>>
>>> Argyrios, would just removing all the LLVM_ATTRIBUTE_USEDs on
>>> dump methods in clang be fine with you? That sounds like the
>>> simples change, and it would be consistent with what's done in llvm.
>>
>> Are you suggesting that one should add 'LLVM_ATTRIBUTE_USED'
>> locally and rebuild if s/he wants to dump something in the debugger ?
>>
>>
>> Yes.
>
> I don't like this at all, I use the dump methods in the debugger all
> the time, I don't want to perpetually have local changes in order to
> use them.
I very strongly second this. I would be in complete opposition to any
proposal which has the effect of worsening the out-of-box debugging
experience.
I understand and support your desire to reduce size in Release builds.
Can you spell out a case for such reduction in Debug builds? Maybe
there's something I'm missing here.
Philip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140102/a7e93323/attachment.html>
More information about the cfe-dev
mailing list