[PATCH] D48651: [RFC] Pattern matching on schedule trees.

[Philip Pfaffe via Phabricator via llvm-commits]

philip.pfaffe added a comment.

> I don't know when and how mainline isl will provide maintained C++ bindings, but the idea there is that `enum isl_schedule_node_type` will not be visible from C++.  This is essentially a trick to have "inheritance" on node types in C.  Practically, isl is going towards individual node types being specific classes that inherit from the generic `schedule_node` one.  They are likely to feature `isa<>`-style interface.  We can declare a local enum and use it to construct matchers though.

Is there a roadmap or RFC for that? I think that's a great idea.

> The trade-off is that the matchers will not scale to non-structural properties.  If we something closer to AST matchers, we will eventually have structure, traversal and property matchers, which are better off with functions or object constructors.

I'm not sure if we're going to need something as powerful as AST matchers. I usually prefer using a low-tech solution first and upgrade once I know with certainty what I actually need out of my system.

> Between macros and almost identical copy-pasted code, I chose macros.

This wasn't criticism about your use of macros, but that the code //requires// macros.

> The callbacks are intended to control the //matching// itself, not for actions on subtrees.  Although one can use them for actions, I would discourage that.

This absolutely makes sense, but I didn't get that from the original summary. This then also satisfies Micheal's wish for a mechanism to match memory patterns. You can just do that in the callbacks.

My interface above can be easily extended to also incorporate Callbacks in the constructor. I don't have a categorical aversion against the interface proposed in the RFC, but I find the enum-based API much more readable.


Repository:
  rPLO Polly

https://reviews.llvm.org/D48651