[LLVMdev] Static ctors in llvm::Attribute
Chris Lattner
clattner at apple.com
Tue Feb 7 12:01:20 PST 2012
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. A better change would be to replace these with enums, eliminating the whole problem. Are 64-bit enums portable enough to be used here?
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.
-Chris
More information about the llvm-dev
mailing list