[llvm-commits] dependence analysis

[Preston Briggs]

On Wed, Sep 26, 2012 at 1:16 PM, Sebastian Pop <spop at codeaurora.org> wrote:
> Here are some more comments on the data dependence patch:
>
> +  // if (X->isLine() && Y->isPoint()) This case can't occur.
>
> Let's turn this comment into an assert.

OK, thanks.

> +// Sometimes, peeling the first or last iteration of a loop will break
> +// dependences, and we've got flags for those possibilities.
> +// Sometimes, splitting a loop at some other iteration will do the trick,
> +// and we've got a flag for that case. Rather than waste the space to
> +// record the exact iteration (since we rarely know), we provide
> +// a method that calculates the iteration. It's a drag that it must work
> +// from scratch, but wonderful in that it's possible.
>
> This is a good example in which you would have to recompute the
> dependence graph after a loop transform.  Have you thought of how to
> cache and/or transform the dependence graph such that we don't
> recompute the whole dependence graph again and again?

I haven't yet, but remember that I'm not (yet) building a dependence
graph. This pass only provides an entry point for testing the
dependence between two instructions.

For many transforms (and I would have to think carefully about each
one), we can update the dependence graph based on the actual
transformation. Other more aggressive xforms may require complete
recomputation (or perhaps they can be scheduled late, so that the
graph can be abandoned).

> On a similar point, I think that we should be able to restrict the scope
> of the dependence analysis to a loop nest or a part of the code, i.e.,
> the dependence analysis should be a lazy analysis that computes on
> demand the dependence graph for a given loop nest or for a portion of
> code. From what I see in the patch, the dependence analysis is always
> performed on the full function, and that has some problems when the
> function contains side effect statements.

I haven't written anything to build a dependence graph yet; so far,
this analysis is quite lazy in that it does nothing at all unless
directed, and the only thing we can direct it to do is compute what
dependence exists between two instructions. For flexibility, it will
work with any pair of instructions in a function.

I'd like to keep the flexibility since I hope to do xforms, e.g., loop
fusion, whose scope is larger than a single loop nest. I also have
hope that we can eventually use the analysis to assist instruction
scheduling and register promotion (i.e., things no necessarily limited
to loops).

> Polly uses single entry, single exit (SESE) regions, and we would
> need something similar to restrict the analysis of dependences to
> a region of code that is interesting for loop optimizations (i.e., free of
> side effects, etc.). The data dependence graph is specific to that context:
> if the scope changes, the dependence graph changes as well, and thus
> has to be recomputed.

So imagine I were building a dependence graph for the entire
function... I don't understand why we need to avoid statements/calls
with side effects. If there's a call to some unknown function, we'll
note that the call depends (in a confused fashion) on all the memory
refs preceding the call and that all the memory refs after the call
depend on it. Things will work out correctly, just like any other load
or store; the dependences guarantee it.

Now, some engineering care is certainly required to ensure that the
time required to build and the space required to represent a
function-wide dependence graph  is not overwhelming, but it can be
done (we did it at Tera). For a discussion of approaches, see
https://sites.google.com/site/parallelizationforllvm/building-the-dependence-graph

Thanks,
Preston