[cfe-dev] Should dump methods be LLVM_ATTRIBUTE_USED only in debug builds?

[Nico Weber]

On Thu, Jan 2, 2014 at 5:59 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> On Thu, Jan 2, 2014 at 8:46 PM, Philip Reames <listmail at philipreames.com>wrote:
>
>> 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.
>>
>
> I'd like to re-iterate my concrete suggestion. I think that *all* of the
> dump methods in LLVM and Clang should be consistently defined as such:
>
> #if LLVM_ENABLE_DUMP
>   void some_helper_function_only_used_by_dump() const;
>   LLVM_DUMP_METHOD void dump() const;
> #endif
>
> And then I would provide the following defines in Compiler.h or whatever
> header seems appropriate:
>
> #define LLVM_ENABLE_DUMP !defined(NDEBUG) || defined(LLVM_ENABLE_DUMP)
> #define LLVM_DUMP_METHOD LLVM_ATTRIBUTE_NOINLINE LLVM_ATTRIBUTE_USED
>
>
> This ensures that dump methods are always available in assert builds, and
> can be enabled explicitly in no-assert builds as needed (LLVM_ENABLE_DUMP
> comes from configure or cmake), and when dump methods are disabled both
> those methods and everything they use gets pruned out, with no warnings
> about unused private methods etc.
>
> What doesn't work with this approach?
>

I think it's a good suggestion, and it's what we should do.

(Not having the attribute at all seemed simpler, but the feedback is clear
that that doesn't work for some folks.)

Unless someone doesn't like Chandler's suggestion (and assuming he doesn't
beat me to it :-) ) I'll implement this proposal tomorrow afternoon.


>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140102/0f482aff/attachment.html>