[llvm-commits] [llvm] r115927 - in /llvm/trunk: include/llvm-c/Core.h include/llvm/InitializePasses.h lib/Transforms/Scalar/Scalar.cpp lib/Transforms/Utils/CMakeLists.txt lib/Transforms/Utils/Utils.cpp lib/VMCore/Core.cpp

[Owen Anderson]

On Jan 15, 2011, at 11:11 PM, Chris Lattner wrote:

> 
> On Oct 7, 2010, at 10:55 AM, Owen Anderson wrote:
> 
>> Author: resistor
>> Date: Thu Oct  7 12:55:47 2010
>> New Revision: 115927
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=115927&view=rev
>> Log:
>> Next step on the getting-rid-of-static-ctors train: begin adding per-library
>> initialization functions that initialize the set of passes implemented in
>> that library.  Add C bindings for these functions as well.
> 
> Hi Owen,
> 
> This is a really unsatisfactory way to handle this.  Doing this means that Scalar.cpp will depend on *all* of the transformation in the library, so someone linking in scalar.cpp will pull in every single .o file in the archive.  The idea of the previous design was that you'd only link in the passes you actually need.

That is still the case.  There's two kinds of clients that we care about:

1) clang and similar clients, which know upfront which set of passes they care about.  Their passes are explicitly initialized when they call createFooPass().  Since they never call the global initializeScalarOpts(), they don't link in Scalar.cpp, instead only linking in those passes for which they call createFooPass().

2) opt and kin, which need to link/initialize all passes available, so that they can be available from the command line.  These clients do call initializeScalarOpts(), thus forcing linkage of all the passes as desired.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110116/9fbe244a/attachment.html>