search for: passmangers

I wonder in what cases FunctionPass is better that Pass. For example, addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes FunctionPassManager. Another question is about FunctionPassManager::run(Function&) and FunctionPass(Function&). The former calls the later, which is fine, but the latter looks like this: bool FunctionPass::run(Function &F) { if

On Thu, 24 Jun 2004, Vladimir Prus wrote: > I wonder in what cases FunctionPass is better that Pass. For example, > addPassesToEmitAssembly takes PassManger and addPassesToJITCompile takes > FunctionPassManager. Here's a simple way to look at it. Use a Function pass whenever you can. A function pass will always work where a Pass works (it derives from pass as you've noticed),

actually i only created a new Module pass and tried to getAnalysis of MemoryDependenceAnalysis from it, i didn't use TargetData directly to regenerate the error i am attaching a c file containing an example code to regenerate the error. with its Makefile the command line i used is: opt -time-passes -analyze -load ${LLVM_PATH}/Release/lib/.libs/libMYMODULEPASS.so -MyModulePass < test.bc

...imit", cl::Hidden, cl::init(100), 00057 cl::desc("The number of instructions to scan in a block in memory " 00058 "dependency analysis (default = 100)")); The args can be changed using opt, but we are using libclang and libllvm and running pass with llvm passmangers. I know that -mllvm can pass llvm args, but the llvm::cl::ParseCommandLineOptions has some issues with mutlethread and I have reported a bug in https://llvm.org/bugs/show_bug.cgi?id=25735, and we could not use this for now. So if there is another way to pass this memdep-block-scan-limit into th...

Hi, I have trouble making my ProfileInfo-Analysis available in the backend, I have changed llc so it loads the ProfileInfo if requested, the PassManger gives this output: > Target Data Layout > Create Garbage Collector Module Metadata > Basic Alias Analysis (default AA impl) > DWARF Information Writer > No Profile Information > Module Information > ModulePass

On Dec 19, 2011, at 3:04 PM, John Criswell wrote: >>> The alloca in question allocates 22 bytes. The 64-bit load in Kostya's original email is accessing two additional bytes past the end of the alloca (i.e., it is accessing array "elements" a[22] and a[23]). Accessing that memory with a read or write is undefined behavior. The program could fault, read zeros, read