<div dir="ltr">So, I have a bunch of thoughts here.<div><br></div><div>First and foremost, I'm extremely concerned about baking the Pass type into the C API. The on-going work to change how the pass manager works at a fundamental level is going to run completely afoul of this. I would really like to keep this out of the C API which we have to be backwards compatible with until the pass manager work settles down. If we don't, the entire thing is going to be really challenging to make progress on.</div>
<div><br></div><div>Second, why are you defining a new callback type? We have std::function now, so I would expect this to be std::function<void(Pass *)>.</div><div><br></div><div>Third, don't you want to pass the unit of IR which the pass manager just ran to the callback? I don't actually see how to do anything useful with real passes here if you don't know *which* function the pass just ran over... But maybe I missed something in speed reading the patch.</div>
<div><br></div><div>Fourth, the new pass manager is very likely going to want to provide a substantially different API. How should I design and test this? Can I just provide an abstract listening mechanism and trust that you'll stitch things back together?</div>
<div><br></div><div>-Chandler <br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 26, 2014 at 4:20 PM, Juergen Ributzka <span dir="ltr"><<a href="mailto:juergen@apple.com" target="_blank">juergen@apple.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi @ll,<br>
<br>
this patch provides the necessary C/C++ APIs and infastructure to enable fine-<br>
grain progress report and safe suspension points after each pass in the pass<br>
manager.<br>
<br>
Clients can provide a callback function to the pass manager to call after each<br>
pass. This can be used in a variety of ways (progress report, dumping of IR<br>
between passes, safe suspension of threads, etc).<br>
<br>
The run listener list is maintained in the LLVMContext, which allows a multi-<br>
threaded client to be only informed for it's own thread. This of course assumes<br>
that the client created a LLVMContext for each thread.<br>
<br>
Cheers,<br>
Juergen<br>
<br>
<br>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
<br></blockquote></div><br></div>