llvm dev - Jun 2006 - [LLVMdev] Adding an object to llc (analysis pass)

Hi
> Right it does.  However, does something *else* require MParSchedule?  If
> so, what?
Ok, i am writing on a different backend based on the cbackend.

The test usage of this pass looks like this:

void getAnalysisUsage(AnalysisUsage &AU) const {
      AU.addRequired<LoopInfo>();
      AU.addRequired<MParSchedule>();
      AU.setPreservesAll();
}

and then in the runOnFunction pass of this backend:
LI = &getAnalysis<LoopInfo>();
MParSchedule &MPar = getAnalysis<MParSchedule>();
lowerIntrinsics(F);
printFloatingPointConstants(F);
F.renameLocalSymbols();
list<Schedule *>* ScheduleList;
Schedule *currentSchedule;
for (Function::iterator i = F.begin(), e = F.end(); i != e; ++i) {
	for(BasicBlock::iterator j=i->begin(),bbe=i->end();j!=bbe;++j) {
        	BasicBlock *bb;
		if((bb=dyn_cast<BasicBlock>(j))) {
                	ScheduleList=MPar.lookupBasicBlock(bb);
                        if(ScheduleList) {
                        	cerr<<"Schedule List:
"<<bb->getName()<<endl;
                                for(list<Schedule*>::iterator 
lsi=ScheduleList->begin(),lse=ScheduleList->end();lsi!=lse;++lsi) {
				cerr<<(*lsi)->cycle<<"
"<<(*(*lsi)->instr);
				}
	                     	cerr<<endl;
			} else cerr<<"Schedule not found"<<endl;
             	} else cerr<<"Instruction not a basic
block"<<endl;
	}
}
return false;

Compiling and linking works fine but
llc -f -march my_backend a.out.bc
gives this error:
llc: PassManagerT.h:387: void
llvm::PassManagerT<Trait>::markPassUsed(const
llvm::PassInfo*, llvm::Pass*) [with Trait = llvm::MTraits]: Assertion 
`getAnalysisOrNullUp(P) && 
dynamic_cast<ImmutablePass*>(getAnalysisOrNullUp(P)) && "Pass
available but
not found! " "Perhaps this is a module pass requiring a function
pass?"'
failed.
llc((anonymous namespace)::PrintStackTrace()+0x1f)[0x880791f]
/lib/tls/libc.so.6(abort+0x1d2)[0xb7da7fa2]
/lib/tls/libc.so.6(__assert_fail+0x10f)[0xb7da02df]
llc(llvm::PassManagerT<llvm::MTraits>::markPassUsed(llvm::PassInfo const*,
llvm::Pass*)+0xf6)[0x8736c36]
Aborted

Poking around i tried to inherit the MParSchedule Pass from ImmutablePass then 
i get an different error:
llc: /work0/tstone/llvm-1.7/include/llvm/Pass.h:185: AnalysisType& 
llvm::Pass::getAnalysisID(const llvm::PassInfo*) const [with AnalysisType = 
llvm::FindUsedTypes]: Assertion `i != AnalysisImpls.size() &&
"getAnalysis*()
called on an analysis that was not " "'required' by
pass!"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x1f)[0x8807aaf]
/lib/tls/libc.so.6(abort+0x1d2)[0xb7d98fa2]
/lib/tls/libc.so.6(__assert_fail+0x10f)[0xb7d912df]
llc(llvm::FindUsedTypes& 
llvm::Pass::getAnalysisID<llvm::FindUsedTypes>(llvm::PassInfo const*) 
const+0xa5)[0x8173da5]
[0x8995e54]
make: *** [a.out.s] Aborted

Thanks for your help
ST

On Thu, 1 Jun 2006, Silken Tiger wrote:
>> Right it does.  However, does something *else* require MParSchedule? 
If
>> so, what?
> Ok, i am writing on a different backend based on the cbackend.
Ok.
> The test usage of this pass looks like this:
>
> void getAnalysisUsage(AnalysisUsage &AU) const {
>      AU.addRequired<LoopInfo>();
>      AU.addRequired<MParSchedule>();
>      AU.setPreservesAll();
> }
>
> and then in the runOnFunction pass of this backend:
> LI = &getAnalysis<LoopInfo>();
> MParSchedule &MPar = getAnalysis<MParSchedule>();
So again, this is the problem I described earlier:  you have a pass 
(MParSchedule) which is a basic block pass.  This pass is being required 
by another pass (your C backend-based thing) which is not a basic block 
pass.  This is the problem, please see the "how to write a pass" doc. 
The
fix is to change MParSchedule to be a function pass or modulepass.

-Chris

-- 
http://nondot.org/sabre/
http://llvm.org/

Hi Chris and llvm list

Thanks for your answer.
> So again, this is the problem I described earlier:  you have a pass 
> (MParSchedule) which is a basic block pass.  This pass is being required 
> by another pass (your C backend-based thing) which is not a basic block 
> pass.  This is the problem, please see the "how to write a pass"
doc.  The
> fix is to change MParSchedule to be a function pass or modulepass.
Ok, after combining all your comments in this thread and reading the
documentation again. I think i figured it out:
Every Pass is allowed to depend on the same granularity (eg. ModulePass
on ModulePass) or coarser (eg. BasicBlockPass on Functionpass but *NOT*
the other way round).

So my here goes my problem: Since my C-Backend modified pass is a module
pass i can only depend on module passes. This stands in contrary to the 
proposed way to use the most apropriate (BasicBlock in my case) pass available.
Since there is no way for me in using this pass?

On a sidenote i have promised to update the documentation if i get my pass
running.
Is the documentation in revision control somewhere to create my diff against it?

Thanks
ST