[PATCH] D73801: [LoopFission]: Loop Fission Interference Graph (FIG)

[Michael Kruse via Phabricator via llvm-commits]

Meinersbur added a comment.

In D73801#1901817 <https://reviews.llvm.org/D73801#1901817>, @bmahjour wrote:

> I tried to engineer an example that would introduce a cycle with input dependency being a critical edge, but I failed. If you have such an example it would be interesting to look at.




  for (int i = ...) {
    p = A[i-1];
    x = load *p;    
  
    y = load *q;
    A[i] = y;
  }

Lets assume AA knows that A and {q,p} do not alias (e.g. TBAA). It is legal to distribute to

  for (int i = ...) {
    y = load *q;
    A[i] = y;
  }
  for (int i = ...) {
    p = A[i-1];
    x = load *p;    
  }

There is a dependency chain `y = load *q;` ->`A[i] = y;` -> `p = A[i-1];` -> `x = load *p;`. The input dependency `x = load *p;` -> `y = load *q;` closes the cycle. It should be even easier to do with instructions that read and write at the same time (e.g. call to memcpy), but DependencyInfo does not support them.

What's even weirder is that this depends on the instruction order on the IR. If we reorder `x = load *p` and `y = load *q`, and (IIUC) DDG only adds unordered (= input) dependencies in forward direction, we get the dependency  `y = load *q;`  -> `x = load *p;`, which is transitively redundant.

I strongly feel that input dependencies should not be part of the DDG.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73801