[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"> 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.<br></blockquote><br>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:<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? 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> 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.</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