[LLVMdev] Static ctors in llvm::Attribute

[Kostya Serebryany]

I see the problem.
Let me try to come up with a solution that does not involve constructors
but also does not sacrifice type safety.

On Tue, Feb 7, 2012 at 12:01 PM, Chris Lattner <clattner at apple.com> wrote:

> Hi Kostya,
>
> One unexpected piece of fallout in your recent attributes change (r148553)
> was that it introduced a bunch of static constructors into .o files that
> #include Attributes.h, due to stuff like this:
>
> const Attributes None      (0);     ///< No attributes have been set
> const Attributes ZExt      (1<<0);  ///< Zero extended before/after call
> const Attributes SExt      (1<<1);  ///< Sign extended before/after call
> const Attributes NoReturn  (1<<2);  ///< Mark the function as not returning
>
> We really don't like static ctors in LLVM, because it is often used as a
> library, and they cause startup-time performance hits and other bad news.
>  I'm surprised we don't have an explicit section about it in the
> CodingStandards, but we do have:
> http://llvm.org/docs/CodingStandards.html#ll_iostream
>
> ... which talks about the same thing.
>
> Anyway, as it turns out, LLVM can optimize those static ctors away in some
> cases, but not all (e.g. -O0).  This was found because LLDB builds with
> -Wstatic-constructor and this header change is causing a flood of warnings.
>
>
> I can think of two ways to fix this.  One is to replace all of these with
> "get" functions, which would be really really ugly.


grrrr

> A better change would be to replace these with enums, eliminating the
> whole problem.  Are 64-bit enums portable enough to be used here?
>

We had a problem with 64-bit enums on the windows side, so I guess the
answer is "not portable"


>
> If not, we could split this into two enums (one for attributes 0-31 and
> one for attributes 32+), and define the appropriate constructors in
> Attribute that take them, and define the appropriate operator|
> implementations that merge them (returning an Attribute).
>
> Can you take a look at this?  It's a pretty big problem for LLDB and other
> clients that use -Wstatic-constructor.
>

--kcc

>
> -Chris
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20120207/34d6f86c/attachment.html>