[Blog] Polyhedral Compilation #433
Conversation
There was a problem hiding this comment.
Thanks for the detailed writeup! This was definitely a hard thing to do, but you made a good case for why you wanted to start from scf/memref and not affine. I think it's pretty cool that you were able to get the domains constructed using isl at all. It of course would have been better to get real code emitted and executing so you can check correctness, but this was a good start.
I just have a few high-level comments on the text.
|
|
||
| Having identified regions with polyhedral domain, the next step is to construct those domains explicitly in a format that can be manipulated by integer programming tools. We use [isl](https://libisl.sourceforge.io/) to build sets from affine constraints and discharge queries such as emptiness checking. | ||
|
|
||
| For a given operation, we begin by determining the space in which its iteration domain should be constructed. This determination depends on the SCoP in which the operation resides: loop induction variables within the SCoP correspond to dimensions of the space, while other variables correspond to parameters. |
There was a problem hiding this comment.
I think this is just my ignorance about the polyhedral model showing, but I don't quite grok what "space" and "dimensions" mean concretely here. Maybe it would be helpful to add a little context-setting above about what isl defines a "domain" to be? What are all the ingredients required to create an iteration domain?
|
|
||
| To construct the iteration domain, we traverse the loop nest moving outwards from the operation, accumulating constraints imposed by loop bounds and `if` conditions, until we reach the root of the SCoP. Each constraint we encounter introduces an inequality between affine expressions. We convert these expressions from MLIR `Value`s into isl's internal representation of affine functions, construct integer sets corresponding to the inequalities, and finally compute the intersection across all constraints. | ||
|
|
||
| In the implementation, this analysis is wrapped up in an MLIR pass that annotates each operation in the IR with an attribute encoding the operation's iteration domain. The figure from the introduction was generated from the pass' output. |
There was a problem hiding this comment.
Do you think you could include one or two examples of what that annotation looks like, in MLIR syntax? I know it will be messy, but I think it would be helpful to get a concrete picture of what the domain consists of, in a way that is separate from the internal isl data structures.
|
|
||
| Testing the legality of transformations in the polyhedral model requires encoding dependence relations between statement executions. Dependences arise from accesses to a common memory location, where one access is a store. There are many techniques for identifying such dependences; following Bastoul, we take the approach of dependence polyhedra. | ||
|
|
||
| A dependence polyhedron, for a given pair of statements, encodes dependences between executions of the respective statements as integer points. The question of whether the statements are free of dependences then amounts to an emptiness check on the polyhedron. |
There was a problem hiding this comment.
FWIW, it took me a couple tries to understand this paragraph: namely, each dependence is one point, so the set of all dependencies is a polyhedron (a set of points).
|
|
||
| ## Evaluation | ||
|
|
||
| Unfortunately, the project has not reached a point where it is practical to perform a systematic evaluation across a wide range of benchmarks. To check correctness, I have thus far relied on manual inspection of the internal data structures. I've tested with a modest set of examples from the literature, with mostly encouraging results. |
There was a problem hiding this comment.
That's OK! Can you say a bit more about what that modest set of examples consists of?
|
|
||
| With respect to the implementation itself, construction of the dependence polyhedra was certainly the trickiest part, and is also the part of the implementation in whose correctness I'm least confident. And as I mentioned above, testing is currently limited to manual inspection of internal data structures (though I did write utilities to visualize those structures where appropriate). | ||
|
|
||
| ## References |
There was a problem hiding this comment.
I don't think you need this section heading; the footnote will be rendered in a way that makes it clear it's not part of the body text. 😃
Closes #405.