From: Chris Lattner Date: Wed, 8 Feb 2012 01:44:00 +0000 (+0000) Subject: add an explicit section on static constructors. X-Git-Url: http://demsky.eecs.uci.edu/git/?a=commitdiff_plain;h=9b6e59d903e38756899e78b489c1673b7a965615;p=oota-llvm.git add an explicit section on static constructors. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150037 91177308-0d34-0410-b5e6-96231b3b80d8 --- diff --git a/docs/CodingStandards.html b/docs/CodingStandards.html index 7b05573703b..a5f6f35b670 100644 --- a/docs/CodingStandards.html +++ b/docs/CodingStandards.html @@ -31,6 +31,7 @@ Errors
  • Write Portable Code
  • Do not use RTTI or Exceptions
    • +
  • Do not use Static Constructors
  • Use of class/struct Keywords
    • @@ -447,6 +448,51 @@ than dynamic_cast<>.

    + +

    +Do not use Static Constructors +

    +
    + +

    Static constructors and destructors (e.g. global variables whose types have +a constructor or destructor) should not be added to the code base, and should be +removed wherever possible. Besides well known problems +where the order of initialization is undefined between globals in different +source files, the entire concept of static constructors is at odds with the +common use case of LLVM as a library linked into a larger application.

    + +

    Consider the use of LLVM as a JIT linked into another application (perhaps +for OpenGL, custom languages, +shaders in +movies, etc). Due to the design of static constructors, they must be +executed at startup time of the entire application, regardless of whether or +how LLVM is used in that larger application. There are two problems with +this:

    + +
      +
    1. The time to run the static constructors impacts startup time of + applications — a critical time for GUI apps, among others.
      2. + +
    2. The static constructors cause the app to pull many extra pages of memory + off the disk: both the code for the constructor in each .o file and + the small amount of data that gets touched. In addition, touched/dirty pages + put more pressure on the VM system on low-memory machines.
      3. +
    + +

    We would really like for there to be zero cost for linking in an additional +LLVM target or other library into an application, but static constructors +violate this goal.

    + +

    That said, LLVM unfortunately does contain static constructors. It would be +a great project for someone to purge all +static constructors from LLVM, and then enable the +-Wglobal-constructors warning flag (when building with Clang) to ensure +we do not regress in the future. +

    + +
    +

    Use of class and struct Keywords @@ -1151,22 +1197,10 @@ prefer it.

    The use of #include <iostream> in library files is -hereby forbidden. The primary reason for doing this is to -support clients using LLVM libraries as part of larger systems. In particular, -we statically link LLVM into some dynamic libraries. Even if LLVM isn't used, -the static constructors are run whenever an application starts up that uses the -dynamic library. There are two problems with this:

    - -
      -
    1. The time to run the static c'tors impacts startup time of applications - — a critical time for GUI apps.
      2. - -
    2. The static c'tors cause the app to pull many extra pages of memory off the - disk: both the code for the static c'tors in each .o file and the - small amount of data that gets touched. In addition, touched/dirty pages - put more pressure on the VM system on low-memory machines.
      3. -
    - +hereby forbidden, because many common implementations +transparently inject a static constructor into +every translation unit that includes it.

    +

    Note that using the other stream headers (<sstream> for example) is not problematic in this regard — just <iostream>. However, raw_ostream provides various