llvm dev - Nov 2010 - [LLVMdev] --enable-optimized breaks pass registration for dynamically loadable passes?

Hello all,

Is it well known that building LLVM with --enable-optimized causes
RegisterPass calls to be removed from dynamically loadable libraries
(i.e., those built with LOADABLE_MODULE=1)?

For example, here's what happens to the Hello pass (ToT on Darwin,
both with and without --enable-optimized):

$ pwd
/Users/ransford/llvm/lib/Transforms/Hello
$ nm -j Release+Asserts/Hello.o | c++filt -p | grep llvm::RegisterPass
$ nm -j Debug+Asserts/Hello.o | c++filt -p | grep llvm::RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello>::RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello>::RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello>::~RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello>::~RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello2>::RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello2>::RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello2>::~RegisterPass
llvm::RegisterPass<(anonymous namespace)::Hello2>::~RegisterPass

As you might expect, after 'make install' installs the libLLVMHello
library, 'opt -load libLLVMHello.dylib -help' shows hello and hello2
in the pass list for the Debug version but not for the Release
version.  Maybe I'm misunderstanding how dynamically loadable pass
modules are supposed to work, but I can't imagine that this behavior
was intentional.

I realize the Hello pass isn't top priority, but I'm developing my own
passes that live in dynamically loadable modules, and I'd like to help
clarify this in the docs if someone explains it to me.

-ben

On Mon, Nov 15, 2010 at 2:57 PM, Ben Ransford <ransford at cs.umass.edu>
wrote:
> Is it well known that building LLVM with --enable-optimized causes
> RegisterPass calls to be removed from dynamically loadable libraries
> (i.e., those built with LOADABLE_MODULE=1)?
Seems like I might have barked up the wrong tree.  I've shortened my
question above to make it more readable in the hopes of garnering a
reply.  I'll also ask an easier question: is it discouraged to put
custom passes in dynamically loadable libraries?  Reading between the
lines of recent developments, the fact that such passes still use the
"legacy" pass registration mechanism (if it's fair to call it
that)
halfway suggests that I shouldn't be putting my passes in dynamically
loadable libraries -- correct me if I'm wrong.  But it's the cleanest
option I'm aware of for maintaining my pass code outside the LLVM
tree.

-ben