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

[Andrew Trick]

Hi Chandler,

I appreciate your reviewing this. Passing arguments to the callbacks was an afterthought and not carefully considered. I’m fine with an API that does not pass anything back to the client, which would serve our needs. A more informative API could be added later if someone ever needs it. It just seemed considerate to generalize and avoid API extension later. Let’s see if we can get the C API right. If not, we can fall back to something simpler.

I don’t understand how the C API implies a base class, but that isn’t listed among your concerns below.

On Apr 29, 2014, at 1:00 PM, Chandler Carruth <chandlerc at google.com> wrote:

> 1) You expose the set of IR units which passes can operate on in the number and types of arguments to the C API. This completely breaks extension in the future.

I’m fine with an opaque PassRun (or PassInvocation, PassInstance, you choose). We should support getting the pass name from the client for basic diagnostics. Beyond that, we can add C API to query the pass information later, if anyone ever cares.

LLVMAddPassRunListener(void *Handle, LLVMContextRef, LLVMPassRunRef)

> 2) The list of IR units is simply wrong.
> 2a) We don't want to expose basic block passes. We only have four of them, and most are used in the standard compilation model.
> 2b) You don't expose the CGSCC passes. The CGSCC pass manager is a fundamental component of the LLVM optimizer. I don't know what use this serves if we can't interact with those.
> 2c) You also don't expose the Loop passes. Maybe we shouldn't have them, maybe we should, but today we definitely have them and they are critical.

N/A. See #1.

> 3) I share Duncan's concerns that it is extremely unclear exactly at what event these callbacks are triggered. The documentation is very sparse there.

Totally agreed, we spoke about this being *after* pass completion, but it didn’t come across well in the API. It should be called postRun.

> 4) A fundamental aspect of the new design is that analysis passes are cached dynamically so that we can access function analyses from non-function passes (and other benefits, such as not invalidating analyses when passes fail to change anything). I don't understand how these will interact with that model. Perhaps this is just a specific example of #3?

I don’t think this needs to be called back after analyses, only transforms. It seems trivial and important to be able to add callbacks after each pass regardless of the passmanager implementation.

> 5) How does this work in a world where we parallelize the pass manager? This is particularly concerning as the discussion seems to indicate that there are thread safety guarantees made by the pass manager in its invocation of these callbacks, and I don't know how to parallelize the pass manager and preserve them.

This is not about thread safety, it’s about thread scheduling. The runtime should be able to see how long an LLVM thread is taking and deprioritize it. So, it would be nice if you’re not holding a mutex when you make the callback.

MCJIT clients need to be able to force one thread per module. If they instead ask for a parallel passmanager, then I guess they’ll get what they ask for. I’m not concerned about this, but if you want to outline how the parallel pass manager will work (or maybe I missed it), then I could invent a strawman for how an MCJIT client would deal with it.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140429/60509e62/attachment.html>