[PATCH] D83372: Fix for memory leak reported by Valgrind

[Chris Bieneman via Phabricator via llvm-commits]

beanz added a comment.

There are a lot of downsides to global constructors. One is that they are difficult to debug because the code runs before `main`, so if anything goes wrong callstacks are odd, debuggers sometimes struggle to attach, and general headaches ensue.

Additionally global constructors are an always-paid performance hit. Local statics are only constructed if they are used, but global statics are always constructed, and transitively they construct anything else they use. This can severely impact the process launch time of a program and it is very difficult to optimize around (other than just not using global constructors). While process launch time may not be something most applications care about because it "only happens once" for a compiler that can be invoked tens or hundreds of thousands of times per day per user, that cost really adds up.

The last big issue with global constructors in LLVM is that LLVM is used as a library in many contexts, and global constructors (and generally global variables) cause lots of issues with that. One of the big problems with using global constructors in library code is that it is really easy to get multiple copies of the globals embedded into the same process. This generally happens when you have a single executable that links two libraries that both include parts of LLVM (in particular libLLVMSupport which you usually want to be able to inline/LTO across). There have been periodic pushes to clean up the global variables, and most of the ones in LLVM today are `cl::opt` objects which need a re-design to clean up.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D83372/new/

https://reviews.llvm.org/D83372