[PATCH][PM] Add pass run listeners to the pass manager.

[Juergen Ributzka]

Hi Chandler,

I have a quick question for you. Are any of the remaining issues related to the C API?
If not, I would like to lock down the C API rather sooner than later. We can fix the
implementation details of the stuff that happens behind the curtains in followup commits.

Thanks

Cheers,
Juergen


On May 7, 2014, at 1:30 PM, Juergen Ributzka <juergen at apple.com> wrote:

> ping :-)
> 
> On May 1, 2014, at 5:17 PM, Chandler Carruth <chandlerc at google.com> wrote:
> 
>> (just FYI, i'd like to bikeshed the names and details some, but i think this is close. will write more details as soon as i have time)
>> 
>> 
>> On Thu, May 1, 2014 at 4:42 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote:
>> 
>> On 2014-May-01, at 15:07, Juergen Ributzka <juergen at apple.com> wrote:
>> 
>> > Hi @ll,
>> >
>> > I incorporated your suggestions into this patch. It extends the pass listener to also work with the new pass manager. There is some additional glue that can be removed
>> > once we get rid of the legacy pass manager. The C API has been reworked to accommodate future changes and additions to the pass listener.
>> >
>> > The callback function signature has changed to incorporate an opaque user defined value and abstracts the current pass and IR behind a pass invocation reference.
>> > The invocation type specifies when this callback has been called. Currently this supports pre- and post-pass notification callbacks.
>> >
>> > void (*LLVMPassListenerCallback)(void *Opaque, LLVMContextRef C, LLVMPassInvocationType T, LLVMPassInvocationRef P);
>> >
>> > The pass invocation reference currently only supports one API - the pass name. This could be extended in the future to obtain the pass related IR, more pass related
>> > information, etc.
>> >
>> > Cheers,
>> > Juergen
>> >
>> > <0001-PM-Extend-pass-listener-to-also-work-with-the-new-pa.patch>
>> 
>> I like the PassInvocation design.  I wasn't quite sure what you were
>> planning here, but I think it solves the "what to pass back" problem
>> quite neatly, giving us flexibility in the future to expand the API.
>> 
>> This LGTM, with the following whitespace nitpick.
>> 
>> > @@ -1618,12 +1618,15 @@ MPPassManager::runOnModule(Module &M) {
>> >
>> >      initializeAnalysisImpl(MP);
>> >
>> > +    M.getContext().notifyPassPreRunListeners(MP, &M);
>> >      {
>> >        PassManagerPrettyStackEntry X(MP, M);
>> >        TimeRegion PassTimer(getPassTimer(MP));
>> >
>> >        LocalChanged |= MP->runOnModule(M);
>> >      }
>> > +    M.getContext().notifyPassPostRunListeners(MP, &M);
>> > +
>> 
>> You inserted an extra newline here.
>> 
>> >
>> >      Changed |= LocalChanged;
>> >      if (LocalChanged)
>> >
>> 
>> 
> 
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140508/fc96c446/attachment.html>