[LLVMdev] Passes calling

[Andrew Trick]

On Jun 13, 2014, at 3:28 AM, Chandler Carruth <chandlerc at google.com> wrote:

> 
> On Fri, Jun 13, 2014 at 11:04 AM, Andrew Trick <atrick at apple.com> wrote:
> Sure, I’m just gently floating some ideas without spending much time understanding how the new design works.
> 
> The part that seems limiting to me is that a transform has to return a set of invalidated analysis. I supposed that set by default contains all the cached analyses and the transform selectively prunes what it preserves?
> 
> Not at all.
> 
> The transform has to return a set of preserved analyses. This is more like the existing system where the assumption is conservative. Again similar to the existing system, it should be possible (although I've not yet made it this far) to preserve an abstract set of analyses such as all those only tied to the CFG.

Right.

> As for your hypothetical example, I'm not really sure what concrete things you have in mind, but I'm pretty sure it will be possible based on your description.
> 
> Notably, the analysis actually gets to handle the invalidation event, and at that time even gets a new reference to the IR. It get's to then *ignore* the invalidation request by updating its internal state as needed. Similarly, it gets lots of information about what was invalidated by the transform.

Yes, that’s one of the features I was asking for.

> The thing that doesn't really seem likely to work the way you describe is that I don't think the *default* behavior will involve mid-transform invalidation of analyses. The cached analyses are typically invalidated between transformations. However, there is an explicit API for directly invalidating, updating, etc. the analysis cache so more things are possible even if they aren't the default behavior.

The important thing to me is that the API exists and it is possible. The default behavior can be similar to what we have with the LegacyPassManager.

-Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140613/ba9ea685/attachment.html>