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

[Oleksandr "Alex" Zinenko via Phabricator via llvm-commits]

ftynse added a comment.

> This was how my API worked:

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.  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 prefer not using macros.

Between macros and almost identical copy-pasted code, I chose macros.  Arguably, it can be rewritten with more templates where the almost-identical part is a one-liner.  If the inheritance-based interface to trees is provided, we can think of something like

  match<isl::schedule_node_domain>(
    match<isl::schedule_node_context>(
      match<isl::schedule_node_band>()))

although it does look more verbose.

> With this implementation you get only one callback per full match, not per matched subtree, but I felt like this is all I needed.

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.  In practice, I often needed to match more than just a node type: filters involving specific statements, mapping to gpu blocks, marks with specific ids, etc.  While it is possible to first collect all subtrees with the matching structures, and then filter them for the desired properties, it looks easier to not match such subtrees in the first place.  When the desired properties are well-defined, one can build a higher-level API around these callbacks, like

  auto isKernel = [](isl::schedule_node mark) {
    return mark.node_mark_get_id() == isl::id(mark.get_ctx(), "kernel");
  };
  auto matcher =
      mark(isKernel,
        context(
          band()));

or even

  template <typename... Args>
  Matcher kernel(Args... args) {
    return mark(isKernel, args...);
  }
  auto matcher = 
      kernel(
        conext(
          band()));


Repository:
  rPLO Polly

https://reviews.llvm.org/D48651