[prev in list] [next in list] [prev in thread] [next in thread] 

List:       llvm-dev
Subject:    Re: [LLVMdev] MAJOR API CHANGE: Pass initialization without static
From:       Owen Anderson <resistor () mac ! com>
Date:       2010-10-11 20:08:35
Message-ID: A184029F-C44F-4520-BFFF-234161FE0029 () mac ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


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


[Attachment #5 (text/html)]

<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
-webkit-line-break: after-white-space; "><div>John,</div><div><br></div><div><div>On \
Oct 8, 2010, at 1:05 PM, John Criswell wrote:</div><blockquote \
type="cite"><div><blockquote type="cite"> &nbsp;&nbsp;These initialization routines \
must be invoked before the PassManager will be able to resolve pipelines involving \
your pass. &nbsp;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.<br></blockquote><br>From an ease of programming perspective, \
this solution is not ideal as what we had before. &nbsp;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. &nbsp;Could you devise something better? \
&nbsp;For example, could you extend PassManager with a method that calls all of the \
passes's initialization methods? &nbsp;In other words, could you easily support \
something like:<br><br>PassManager.add (Pass1);<br>PassManager.add \
(Pass2);<br>...<br>PassManager.add (PassN);<br>PassManager.initializeAllPasses \
();<br>PassManager.run();<br><br><br>... or could the PassManager::add() method \
automatically initialize the pass? &nbsp;Other possibilities may exists which are \
better as well; these are just the first two I've thought \
of.<br></div></blockquote></div><br><div>&nbsp;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). &nbsp;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.</div><div><br></div><div>I'm \
putting my current patch (implementing the old version of this proposal) on hold to \
evaluate the possibility of going this route \
instead.</div><div><br></div><div>--Owen</div></body></html>



_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic