Re: [PATCH 0/3] Fix PR47654 and PR49649

[Sebastian Pop <sebpop@gmail.com>]

Hi Tobias,

On Sat, Jul 16, 2011 at 20:02, Tobias Grosser <tobias@grosser.es> wrote:
> Here I am a little lost. You write using the precise method you get an
> interval [0,99] for the example in vect-pr43423.c. This is the example:
>
> int a[100], b[100], c[100];
>
> void foo(int n, int mid)
> {
>  int i;
>  for(i=0; i<n; i++)
>    {
>      if (i < mid)
>        a[i] = a[i] + b[i];
>      else
>        a[i] = a[i] + c[i];
>    }
> }
>
> I do not see, how you would derive this small type, as the parameters of
> function foo() allow a range that is a lot larger.

Accessing a[100] is undefined in C, so i < 100, and so n <= 100.

>> #  Access function 0: (int) {(<unnamed-unsigned:8>) graphite_IV.7_56, +,
>> 1}_3;
>> #)
>> affine dependence test not usable: access function not affine or constant.
>>
>> So we have to keep around the previous code gcc_type_for_clast_* that
>> computes the type of an expression as the max precision of the
>> components of that expression, and use that when computing the types
>> of substitution expressions.
>
> Here I am lost again. I understand that very small types may introduce more
> casts (and casts are always difficult to analyze). However, I do not
> understand your solution.
>
> First of all it seems the gcc_type_for_clast ... functions are always needed
> to calculate the types, as just using polyhedral methods would not get
> larger types, as they may be needed for intermediate results. Which
> functions in your patch (or in the current graphite code), are only needed
> to ensure that no problematic casts are inserted? This would probably help
> me to understand how they ensure no problematic casts are generated.

The current graphite code contains the gcc_type_for_clast functions
that are computing wide enough types for expressions.  The types are
computed based on the types of parameters and based on the types of
the induction variables of the loops surrounding the statement using
that expression.  These functions are not touched by the current patch
set.

The functions lb_ub_for_* added by this patch are the ones that will
be very precise on the lower bound and upper bounds, as they are
computing based on the polyhedral representation, instead of asking
for the type of parameters, or the type of induction variables in an
expression.  The lb_ub_for_* functions are too precise to compute the
type of expressions other than the loop bounds.  This extra precision is
needed to address the problem you exposed of increasingly wider types
for inductions variables.

> P.S.: I would love to see this upper/lower bound calculation being part of
> CLooG.
>

Yes, that would be nice.  Let's convince skimo that we would need types
on CLAST expressions ;-)

Sebastian