Shuguang Feng
2009-Sep-09 22:15 UTC
[LLVMdev] [PATCH] & Question: Preserving ProfileInfo for backend.
Thanks for such a rapid response!> Don't know about Passes in the backend, but this could be a problem of > an FunctionPassManager trying to use a ModulePass.I manually applied the patch you provided for llc (I'm using the 2.5 release of LLVM not ToT) and it fixed my compilation error. When your patch replaced the FunctionPassManager used by llc with a PassManager the error went away. Unfortunately, I'm still seeing execution counts of -1 when I print them out in my MachineFunction pass. I access the profiling information at each MachineBasicBlock with the following code, where "bb" is a reference to the current MachineBasicBlock: PI->getExecutionCount(bb.getBasicBlock()) I believe I've integrated all the ProfileInfo* files from ToT with my LLVM-2.5 installation properly. The profiling code (and llvm-prof) seems to be working since llvm-prof is generating/printing the appropriate execution frequencies. Is there an obvious mistake that I could be making? Since I've had to customize my current installation of llvm I would like to avoid updating to the latest revision if possible. Thanks!
Andreas Neustifter
2009-Sep-10 08:35 UTC
[LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
Hi, Shuguang Feng wrote:> Thanks for such a rapid response! > >> Don't know about Passes in the backend, but this could be a problem of >> an FunctionPassManager trying to use a ModulePass. > > I manually applied the patch you provided for llc (I'm using the 2.5 > release of LLVM not ToT) and it fixed my compilation error. When your > patch replaced the FunctionPassManager used by llc with a PassManager > the error went away. > > Unfortunately, I'm still seeing execution counts of -1 when I print > them out in my MachineFunction pass. I access the profiling > information at each MachineBasicBlock with the following code, where > "bb" is a reference to the current MachineBasicBlock: > > PI->getExecutionCount(bb.getBasicBlock())What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass really the last pass to touch the ProfileInfo before you are using it? Also, does bb.getBasicBlock() for sure always returns a valid block refrerence? You are getting the PI by getAnalysis<ProfileInfo>() I presume? Is this really the instance created by ProfileLoaderPass? (I guess for the last two questions its best to use gdb, are you familiar with it?) Andi
Shuguang Feng
2009-Sep-10 14:44 UTC
[LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
> What does "llc -debug-pass=Structure" say? Is the ProfileLoaderPass > really the last pass to touch the ProfileInfo before you are using it?Below is the sequence of passes that I see. Although the NoProfileInfo pass is being run, it should be subsequently overridden by ProfileInfoLoaderPass (LoaderPass) correct? Target Data Layout Create Garbage Collector Module Metadata Basic Alias Analysis (default AA impl) DWARF Information Writer No Profile Information Module Information ModulePass Manager Profiling information loader FunctionPass Manager Preliminary module verification Dominator Tree Construction Module Verifier Natural Loop Construction Canonicalize natural loops Scalar Evolution Analysis Loop Pass Manager Loop Strength Reduction Lower Garbage Collection Instructions Remove unreachable blocks from the CFG Optimize for code generation Insert stack protectors X86 DAG->DAG Instruction Selection X86 FP_REG_KILL inserter X86 Maximal Stack Alignment Calculator <MY PASS RUNS HERE>> Also, does bb.getBasicBlock() for sure always returns a valid block > refrerence?Yes. I am printing bb and *bb.getBasicBlock() in order to compare the contents of the IR in the BasicBlock and the target assembly in the MachineBasicBlock.> You are getting the PI by getAnalysis<ProfileInfo>() I presume? Is this > really the instance created by ProfileLoaderPass?Yes, I have "PI = &getAnalysis<ProfileInfo>()" in my code (modeled after BasicBlockPlacement.cpp). However, when I run gdb the value of the Pass* pointer returned by createProfileLoaderPass() does not match the value of PI (of type ProfileInfo*) that I see inside my MachineFunctionPass. The abbreviated output of gdb is found below: Breakpoint 1, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/ llc/llc.cpp:292 292 Pass* tmp = createProfileLoaderPass(); (gdb) p tmp $1 = (class llvm::Pass *) 0x3573000 (gdb) c Continuing. Breakpoint 2, main (argc=11, argv=0xbfffd394) at <path to llvm>/tools/ llc/llc.cpp:293 293 Passes.add(tmp); (gdb) p tmp $2 = (class llvm::Pass *) 0x8feeaf0 So the address of the ProfileLoaderPass should be 0x8feeaf0 correct? But I see the following inside my own pass: Breakpoint 3, MyCodeGenPass::runOnMachineFunction (this=0x90be200, MF=@0x90ca280) at <path to llvm>/lib/Target/X86/MyCodeGenPass.cpp:108 108 <random line of code after PI &getAnalysis<ProfileInfo>() executes> (gdb) p PI $3 = (class llvm::ProfileInfo *) 0x90be438> (I guess for the last two questions its best to use gdb, are you > familiar with it?)I have a working knowledge :) but haven't used any bells and whistles. Thanks for your help.
Possibly Parallel Threads
- [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
- [LLVMdev] [PATCH] & Question: Preserving ProfileInfo for backend.
- [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
- [LLVMdev] Loading ProfileInfo in Backend. (Was: [PATCH] & Question: Preserving ProfileInfo for backend.)
- [LLVMdev] [PATCH] & Question: Preserving ProfileInfo for backend.