Pool Allocation Segfaulting with opt

Hi,

I'm trying to run the pool allocation pass through opt, and I'm running into problems. It segfaults frequently; for example, it does this when the input is a simple Hello World program:

[simmon12@apoc testcases]$ opt -load /home/vadve/simmon12/llvm/llvm/projects/llvm-poolalloc/Debug/lib/libLLVMDataStructure.so -load /home/vadve/simmon12/llvm/llvm/projects/llvm-poolalloc/Debug/lib/poolalloc.so -poolalloc hello.bc > hello.pool
0 opt 0x08469ccb
1 libLLVMDataStructure.so 0x0022f5a4 llvm::ConstantArray::classof(llvm::Value const*) + 30
2 libLLVMDataStructure.so 0x0022f57a bool llvm::isa_impl<llvm::ConstantArray, llvm::Constant>(llvm::Constant const&) + 30
3 libLLVMDataStructure.so 0x0022e942 llvm::isa_impl_wrap<llvm::ConstantArray, llvm::Constant const, llvm::Constant const>::doit(llvm::Constant const&) + 30
4 libLLVMDataStructure.so 0x0022e22a bool llvm::isa_impl_cl<llvm::Constant>::isa<llvm::ConstantArray>(llvm::Constant const&) + 30
5 libLLVMDataStructure.so 0x0022e032 bool llvm::isa_impl_cl<llvm::Constant*>::isa<llvm::ConstantArray>(llvm::Constant*) + 30
6 libLLVMDataStructure.so 0x0022dd82 bool llvm::isa<llvm::ConstantArray, llvm::Constant*>(llvm::Constant* const&) + 32
7 libLLVMDataStructure.so 0x0022d9dc llvm::cast_retty<llvm::ConstantArray, llvm::Constant*>::ret_typellvm::dyn_cast<llvm::ConstantArray, llvm::Constant*>(llvm::Constant* const&) + 30
8 libLLVMDataStructure.so 0x0022bc71 (anonymous namespace)::GraphBuilder::MergeConstantInitIntoNode(llvm::DSNodeHandle&, llvm::Type const*, llvm::Constant*) + 229
9 libLLVMDataStructure.so 0x0022bfb7 (anonymous namespace)::GraphBuilder::mergeInGlobalInitializer(llvm::GlobalVariable*) + 149
10 libLLVMDataStructure.so 0x0022c08c llvm::LocalDataStructures::runOnModule(llvm::Module&) + 190
11 opt 0x083fdf4e llvm::MPPassManager::runOnModule(llvm::Module&) + 270
Segmentation fault

I'm using the latest SVN checkouts for both LLVM and llvm-poolalloc. Should I perhaps use the 2.5 branch of LLVM instead?

Oh, also, what's the name of the DSA pass that pool allocation runs? I'd like to structure my passes to go "DSA-MyAnalysis-PoolAllocation-MyTransform".

Thanks,
--Patrick

Patrick Alexander Simmons wrote:

Hi,

I'm trying to run the pool allocation pass through opt, and I'm running
into problems. It segfaults frequently; for example, it does this when
the input is a simple Hello World program:
  

Can you email me the bitcode file that is causing the problem?

[simmon12@apoc testcases]$ opt -load
/home/vadve/simmon12/llvm/llvm/projects/llvm-poolalloc/Debug/lib/libLLVMDataStructure.so
-load
/home/vadve/simmon12/llvm/llvm/projects/llvm-poolalloc/Debug/lib/poolalloc.so
-poolalloc hello.bc > hello.pool
0 opt 0x08469ccb
1 libLLVMDataStructure.so 0x0022f5a4
llvm::ConstantArray::classof(llvm::Value const*) + 30
2 libLLVMDataStructure.so 0x0022f57a bool
llvm::isa_impl<llvm::ConstantArray, llvm::Constant>(llvm::Constant
const&) + 30
3 libLLVMDataStructure.so 0x0022e942
llvm::isa_impl_wrap<llvm::ConstantArray, llvm::Constant const,
llvm::Constant const>::doit(llvm::Constant const&) + 30
4 libLLVMDataStructure.so 0x0022e22a bool
llvm::isa_impl_cl<llvm::Constant>::isa<llvm::ConstantArray>(llvm::Constant
const&) + 30
5 libLLVMDataStructure.so 0x0022e032 bool
llvm::isa_impl_cl<llvm::Constant*>::isa<llvm::ConstantArray>(llvm::Constant*)
+ 30
6 libLLVMDataStructure.so 0x0022dd82 bool
llvm::isa<llvm::ConstantArray, llvm::Constant*>(llvm::Constant* const&) + 32
7 libLLVMDataStructure.so 0x0022d9dc
llvm::cast_retty<llvm::ConstantArray,
llvm::Constant*>::ret_typellvm::dyn_cast<llvm::ConstantArray,
llvm::Constant*>(llvm::Constant* const&) + 30
8 libLLVMDataStructure.so 0x0022bc71 (anonymous
namespace)::GraphBuilder::MergeConstantInitIntoNode(llvm::DSNodeHandle&,
llvm::Type const*, llvm::Constant*) + 229
9 libLLVMDataStructure.so 0x0022bfb7 (anonymous
namespace)::GraphBuilder::mergeInGlobalInitializer(llvm::GlobalVariable*)
+ 149
10 libLLVMDataStructure.so 0x0022c08c
llvm::LocalDataStructures::runOnModule(llvm::Module&) + 190
11 opt 0x083fdf4e
llvm::MPPassManager::runOnModule(llvm::Module&) + 270
Segmentation fault

I'm using the latest SVN checkouts for both LLVM and llvm-poolalloc.
Should I perhaps use the 2.5 branch of LLVM instead?

Oh, also, what's the name of the DSA pass that pool allocation runs?
I'd like to structure my passes to go
"DSA-MyAnalysis-PoolAllocation-MyTransform".
  

You can use the -debug-pass=Arguments option to opt to print out which
DSA passes it is using.

-- John T.

John Criswell wrote:

You can use the -debug-pass=Arguments option to opt to print out which
DSA passes it is using.

-- John T.
  

The argument list was this: -dsa-local -dsa-stdlib -dsa-bu -dsa-eqtd -poolalloc -preverify -domtree -verify

So, the last DSA pass done would appear to have been "-dsa-eqtd". Does this mean pool allocation is using TDeq and not BUeq as I'd thought? I notice that it's doing a BU pass right before it, so I guess that's probably not right, but the source code says that the flag for BUeq is "-dsa-eq", not "-dsa-eqtd", so I'm confused.

--Patrick

Patrick Alexander Simmons wrote:

John Criswell wrote:
  

You can use the -debug-pass=Arguments option to opt to print out which
DSA passes it is using.

-- John T.
  

The argument list was this: -dsa-local -dsa-stdlib -dsa-bu -dsa-eqtd
-poolalloc -preverify -domtree -verify

So, the last DSA pass done would appear to have been "-dsa-eqtd". Does
this mean pool allocation is using TDeq and not BUeq as I'd thought?

That is correct. By default, the Automatic Pool Allocation (APA) pass
will choose eqtd because that is what we want it to use with SAFECode.

If you look at the PoolAllocate constructor, you'll notice a SAFECode
argument that defaults to true. I believe setting it to false will
cause APA to use eq-bu results instead.

I
notice that it's doing a BU pass right before it, so I guess that's
probably not right, but the source code says that the flag for BUeq is
"-dsa-eq", not "-dsa-eqtd", so I'm confused.
  

The EQTD pass requires the TD pass which requires the BU pass which
requires the local pass. That is why you're seeing dsa-bu in the list.

-- John T.