[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [LLVMdev] MAJOR API CHANGE: Pass initialization without static
From:       "Howell, Nathan" <nhowell () ebay ! com>
Date:       2010-10-08 21:17:11
Message-ID: 5EE049BA3C6538409BBE6F1760F328ABEB0189B3D9 () DEN-MEXMS-001 ! corp ! ebay ! com
[Download RAW message or body]

If gcc/ld sort sections alphabetically you could use a technique similar to \
OBJECT_ENTRY_AUTO [1], perhaps like this:

Initializer* llvm_reg_start __attribute__ ((section "_llvm_reg__a")) = NULL;
Initializer* llvm_reg_end __attribute__ ((section "_llvm_reg__z")) = NULL;

#define INITIALIZE_LLVM_PASS (passname, pass) void* llvm_reg_passname __attribute__ \
((section "_llvm_reg__m")) = &pass;

void InitializeAllPasses() {
  // since a < m < z, all of the registered pass pointers should live in \
(llvm_reg_start, llvm_reg_end) after linking  for (Initializer** i = \
++(&llvm_reg_start); i < &llvm_reg_end); ++i) {  Pass::Initialize(*i);
  }
}

[1] http://msdn.microsoft.com/en-us/library/exx3wywe(VS.80).aspx

-----Original Message-----
From: llvmdev-bounces@cs.uiuc.edu [mailto:llvmdev-bounces@cs.uiuc.edu] On Behalf Of \
                John Criswell
Sent: Friday, October 08, 2010 1:55 PM
To: Owen Anderson
Cc: llvmdev
Subject: Re: [LLVMdev] MAJOR API CHANGE: Pass initialization without static \
constructors

  On 10/8/10 3:44 PM, Owen Anderson wrote:
> [snip]
> 
> > Hrm.  I see.
> > 
> > I still don't like the idea of having every statically-linked tool explicitly \
> > initializing every library that gets linked in.  Just dumping the library into \
> > the Makefile and being done with it was much nicer. 
> > If you can find a reasonable way to support that, it would be nice.  However, if \
> > you can't, it's not that big a deal.  As I mentioned before, as long as \
> > out-of-tree passes don't have to modify LLVM source files to work properly, I'll \
> > live.
> I don't especially like it either, but the abundance of static constructors in LLVM \
> has been a long-standing performance concern.  I wouldn't be going this way if I \
> had a better solution.

Okay.  Thanks, Owen.

-- John T.

> --Owen
> 

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


[prev in list] [next in list] [prev in thread] [next in thread]