patch for merging graphite branch (before tuplification)

[Richard Guenther]

On Sun, Aug 3, 2008 at 10:30 PM, Sebastian Pop <sebpop@gmail.com> wrote:
> On Sun, Aug 3, 2008 at 3:20 PM, Richard Guenther
> <richard.guenther@gmail.com> wrote:
>>> If the PPL version affects the code generated by GCC (other than simply
>>> through bugs in PPL) and so the configure tests need to test for *exactly*
>>> a particular version (that we put in the infrastructure directory in
>>> gcc.gnu.org) that complicates use of distributor versions in that each GCC
>>> version will have a required PPL version that may not be the particular
>>> one distributed.  The distributor might override the configure check for
>>> building their own GCC version, as one of the modifications to it - but as
>>> far as possible unmodified FSF GCC should have deterministic code
>>> generation not depending on the versions of libraries it is linked
>>> against, which could limit the utility of distributor versions for people
>>> building FSF GCC themselves on the various distributions.
>>
>> Sure.  But modulo bugs there shouldn't be a difference in code-generation
>> (for the PPL part at least), as it provides "basic math" like mpfr.  Code
>> generation could be affected by the version of Cloog though.
>>
>
> I don't see the point on imposing Cloog to generate the same loops
> output for all the versions.  On the contrary, the output of Cloog
> should improve with time, i.e.  reducing the number of redundant
> constraints is one of the optimizations that Cloog can do, and that we
> should improve.

Sure.  But do you agree that the PPL version (or whether using PPL or
polylib) should not, and is not likely to, change code generation?

> Preventing people to use newer versions of Cloog is not an option.

Of course.

Richard.