[LLVMdev] Pass registered multiple times!

John Criswell criswell at cs.uiuc.edu
Mon Mar 31 13:35:56 PDT 2008

Lu Zhao wrote:
>> If you disassemble your input bytecode file and look at the LLVM
>> disassembly, I'd bet that either __main() and puts are external
>> functions with no function body or are not present in the file at all.
> You're right. The assembly code only has the body of main function and
> the external function declaration puts
> declare i32 @puts(i8*)
> It makes sense, I think, that my derived FunctionPass is not invoked on
> external functions when I intend to optimize code such as C. However,
> if my code was written in LLVM and I wanted to trigger it on all LLVM
> functions including external functions outside the module, how could I
> do it?
Within the PassManager framework, all of your analysis and transforms 
are performed on a single LLVM Module (roughly speaking, an LLVM Module 
represents one LLVM bytecode file).  Depending on what you're doing, you 
can either process each bytecode file separately (e.g., run opt on each 
bytecode file individually), or you can link all the bytecode files 
together into one bytecode file using llvm-ld and run opt on the single 
bytecode file.

The former is good for intra-procedural passes; the latter is good for 
inter-procedural passes (it's what allows LLVM to do inter-procedural 
optimization beyond the boundaries of individual compilation units).

If your pass simply needs to add instructions to empty functions, there 
are two ways to do it.  First, you can make your pass a ModulePass so 
that it can analyze and modify any part of the program at any time.  
Second, as an alternative, you could add a doInitialization() or 
doFinalization() method to your FunctionPass that handles empty functions.

I am assuming that you're writing a pass to be used via opt.  If you're 
doing something more sophisticated (like writing a JIT that dynamically 
loads LLVM bytecode files), then I'm not sure what the right option is.

Does this answer your question?

-- John T.

> Thanks.
> Lu

More information about the llvm-dev mailing list