[PATCH] D68827: [DDG] Data Dependence Graph - Pi Block

[Bardia Mahjour via Phabricator via llvm-commits]

bmahjour added a comment.

In D68827#1726300 <https://reviews.llvm.org/D68827#1726300>, @Meinersbur wrote:

> I am still unconvinced over the boilerplate `createPiBlocks`.


I'm not sure what you mean by "boilerplate". Is it in reference to your concern about de-duplication of edges based on their kinds? If not, could you please elaborate?

> This method of de-duplication of edges assumes that edges are only defined by its kind. Is it correct that no additional properties, such as which definition of a value caused a UseDef dependency, are planned?

Yes, this abstraction loses information about the specific origin of edges coming from inside nodes (members of a pi-block) and the specific target of edges coming from outside nodes. The idea is that since members of a pi-block are bound together by their tight dependence relationship, there is less value in maintaining the coordinates of their relationship with respect to nodes outside of the pi-block. For example, suppose instruction A and B are part of a pi-block (P) and instruction C has a flow dependence with both A and B.  For the purpose of instruction ordering, C will come before (P) by the virtue of a single edge from C to that pi-block. At this point the fact that both A and B are connected to C is irrelevant/redundant. 
There are cases however, where the nature of the dependence relationship is important, for example when determining if a fusion-preventing edge exists between two loops. In such cases the existence of a particular dependence relationship needs to be recomputed, however the specifics of the origin or target of that dependence is not useful. In subsequent patches I'm going to add a function getDependencies() to the DDG where given two nodes (they could be pi-blocks) it walks through their instructions and returns a vector of all the possible dependence relationships between those two nodes.

Please also note that one of the primary goals of creating pi-blocks is to turn the graph into an DAG. If we maintain edges to individual nodes of a pi-block, the cycles in the pi-blocks become exposed again and the purpose of abstraction is defeated.

If the need arises in the future to obtain the lost information, it could be dealt with by

1. recomputing the dependencies between subject nodes
2. maintaining a side table in the builder and/or DDG
3. keeping the original edges and somehow dealing with the DAG issue (not sure if possible).
4. introducing an aggregate edge that keeps track of its origins and targets.

Each approach would have its own challenges of course, but (3) is the only one that would be harder to do in the future if we continue with the proposed implementation.

Do you have a common use-case in mind where it would be important to know exactly which nodes within a pi-block have relationships with nodes that are outside?


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68827/new/

https://reviews.llvm.org/D68827