search for: _zn4llvm11basicaastubev

Okay, the problem with this cycle is LoopSimplify. It is using AliasAnalysis which is where that _ZN4llvm11BasicAAStubEv symbol is coming from. It seems to me that LoopSimplify.cpp is in the wrong place. This file defines the LoopSimplify FunctionPass which doesn't seem to me to be a "transform util". I thought the purpose of "Transforms/Util" was to provide utilities that are common amongst...

...nalysis? If so, its going to take some significant code rearrangement. Perhaps a lib/Analysis/Utils is in order? Please advise. Reid. On Wed, 2006-03-22 at 08:13 -0800, Reid Spencer wrote: > Okay, the problem with this cycle is LoopSimplify. It is using > AliasAnalysis which is where that _ZN4llvm11BasicAAStubEv symbol is > coming from. It seems to me that LoopSimplify.cpp is in the wrong > place. This file defines the LoopSimplify FunctionPass which doesn't > seem to me to be a "transform util". I thought the purpose of > "Transforms/Util" was to provide utilities tha...

...eally, none of the above should depend on libLLVMTransformUtils. Yeah, I'm definitely having headaches with LLVMTransformUtils, which needs to appear before LLVMAnalysis and lLLVMTarget. -lLLVMTransformUtils -lLLVMAnalysis -lLLVMTarget If I don't do this, I get link errors on: __ZN4llvm11BasicAAStubEv I think, for now, the only portable workaround is for me to link all the *.a libraries in that loop twice, and hope we can clean up the dependencies later. There's several places where llvm-config could be simplified quite a bit if we broke the unnecessary dependencies and merged the re...

On Tue, 21 Mar 2006, Reid Spencer wrote: > About the only thing I can suggest are: > > 1. Combine LLVMSparc*.o into one LLVMSparc.a. That work is already > happening with the new Sparc backend that is being developed. Should be > out in 1.7 (Chris?) I wouldn't worry about the SparcV9 backend for your project. > 2. Combine the JIT/Interpreter/ExecutionEngine into one .a