Re: DDG - Implementing Swing Modulo Scheduling in GCC (cont.)

[Ayal Zaks <ZAKS at il dot ibm dot com>]

Vladimir Makarov writes:
>> So in general the data design looks ok to me of course if it is enough
>> for your implementation of SMS.  I've found some simplifications in
>> data
>> analysis.  You are searching dependencies between iterations with only
>> the distance equal to 1.  It is better to use a general framework
>> dependence.c (now it is not a part of gcc mainline because it is not
>> used by any part of gcc

The "dependence.c" currently in tree-ssa is a version of this work, right?

>>                        ) written by Stan Cox.  If it is hard to
>> understand or support this, you could implement at least the same
>> functionality.
>
Daniel Berlin writes:
>I *strongly* recommend against reviving dependence.c, for the following
>reasons:
>1. As submitted, it didn't work (it required some modifications and
>hooks into the c front end that were never committed/approved).
>2. What did "work" (ie when you put in the right hooks) was buggy and
>often segfaulted (i tried to use it for something for about a week or
>two before giving up because it kept segfaulting on trivial code).
>3. It constructs it's own def-use chains from trees
>4. It tries to do dependence on our arbitrarily complex tree structure
>
>
>3 and 4 are artifacts of trying to do dependence without tree-ssa.
>Most of the code in dependence.c was dealing with these def-use chains,
>so you'd be better off not using it as a starting point.
>
>If you must have better tree->rtl dependence info passed down (which is
>what dependence.c did), i'd suggest starting with Sebastian Pop's
>recently posted work, and having the results passed down to the RTL
>level somewhat like dependence.c does.
>
>Though starting with some simple RTL dependence and then using more
>advanced tree dependence info passed down to RTL when tree-ssa arrives
>sounds like a good option.

Our primary concern at the moment is to agree on the API for providing
dependence information to the modulo scheduler. This information includes
dependences carried by the innermost loop only, hence a scalar "distance"
is required instead of a general distance-vector. The analysis used to
compute such dependences can later be enhanced, without changing the API
or the modulo scheduler itself. Currently ddg.c/build_deps() provides a
minimal solution of distance 1, which should cover many interesting cases
btw (e.g. accumulation). It would indeed be great if more advanced tree
dependence info could be passed down to RTL, in the future. Contributions
in this direction of enhancing the dependence analysis are welcome :-)

Ayal.