PassManager vs FunctionPassManager

Right now, addPassesToEmitFile requires a FunctionPassManager. If I'm
working with code that uses a plain PassManager and want it to generate
code, are there any options better than doing this:

/**
* Wrapper class to run a FunctionPassManager as a ModulePass so that it
* can be added to a plain PassManager.
*/
class FunctionPassManagerModulePass : public ModulePass {
  FunctionPassManager &Passes;
public:
  static char ID; // Pass ID, replacement for typeid
  explicit FunctionPassManagerModulePass(FunctionPassManager &FPM) :
    ModulePass((intptr_t)&ID),
    Passes(FPM)
  {}

  bool runOnModule(Module &M) {
    bool Changes = false;

    Changes |= Passes.doInitialization();

    for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I)
      if (!I->isDeclaration())
        Changes |= Passes.run(*I);

    Changes |= Passes.doFinalization();

    return Changes;
  }
};

?

Thanks,

Dan

That's what FPPassManager does (include/llvm/PassManagers.h) . Function pass manager itself is a module level pass. FunctionPassManager is external stand alone interface hence it does not derive from ModulePass.

To be clear, I'm specifically talking about addPassesToEmitFile and
other functions in include/llvm/Target/TargetMachine.h which, as
currently written, require an actual FunctionPassManager. It doesn't
look like FPPassManager is immediately useful here.

Looking at this some more, I'm wondering if it would make sense to
add a run(Module &) method to FunctionPassManager, for this purpose.

Dan

That is not a good idea. The only reason FunctionPassManger exist
is that its user does not want to know that Modules exist somewhere. It
is available mainly for JIT who wants to process Functions on demand.

Instead add new method addPassesToEmitFIle in TargetMachine
that uses FPPassManager for your needs.