[LLVMdev] Static ctors in llvm::Attribute

[Kostya Serebryany]

Another simple solution is to use "typedef uint64_t Attributes " w/o any
enums (just "const uint64_t  None = 0", etc).
This should work now because we already cleaned up all uses of unsigned,
but someone may use unsigned instead of Attributes later.
We can make such bugs easier to discover by moving half of the attribute
constant to the higher 32-bits.
?

--kcc


On Tue, Feb 7, 2012 at 12:53 PM, Kostya Serebryany <kcc at google.com> wrote:

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