[LLVMdev] MAJOR API CHANGE: Pass initialization without static constructors

Owen Anderson resistor at mac.com
Mon Oct 11 13:08:35 PDT 2010


John,

On Oct 8, 2010, at 1:05 PM, John Criswell wrote:
>>   These initialization routines must be invoked before the PassManager will be able to resolve pipelines involving your pass.  For convenience, LLVM now exposes per-library batch initialization routines, i.e. initializeScalarOpts(), which initialize all the passes within a given library in a single go.
> 
> From an ease of programming perspective, this solution is not ideal as what we had before.  Each time I link in a new library into my program, I have to go find the method that initializes all of the passes and remember to call it from my tool.  Could you devise something better?  For example, could you extend PassManager with a method that calls all of the passes's initialization methods?  In other words, could you easily support something like:
> 
> PassManager.add (Pass1);
> PassManager.add (Pass2);
> ...
> PassManager.add (PassN);
> PassManager.initializeAllPasses ();
> PassManager.run();
> 
> 
> ... or could the PassManager::add() method automatically initialize the pass?  Other possibilities may exists which are better as well; these are just the first two I've thought of.

 Chris and I had a discussion about this offline, and he pointed out to me that we could make this API work if we had statically declared pass dependency information (that must be guaranteed to be a superset of the true dynamic dependencies).  If we have that information, then the createPass() methods can be made to call the initializePass(), which can in turn recursively initialize its potential dependencies.

I'm putting my current patch (implementing the old version of this proposal) on hold to evaluate the possibility of going this route instead.

--Owen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20101011/bf73cfe1/attachment.html>


More information about the llvm-dev mailing list