On 06/29/2011 12:35 PM, Sebastian Pop wrote:
2011-06-29 Sebastian Pop<sebastian....@amd.com>
PR tree-optimization/47654
* graphite-clast-to-gimple.c (gcc_type_for_value): Removed.
(gcc_type_for_clast_term): Removed.
(gcc_type_for_clast_red): Removed.
(gcc_type_for_clast_bin): Removed.
(lb_ub_for_expr_name): New.
(lb_ub_for_term): New.
(lb_ub_for_expr): New.
(lb_ub_for_red): New.
(lb_ub_for_bin): New.
(gcc_type_for_clast_expr): Reimplemented.
* graphite-ppl.h (value_min): New.
* gcc.dg/graphite/run-id-pr47654.c: New.
I think the approach you are taking here is correct (in terms of not
producing wrong code).
However I am not sure if this will lead to the smallest type possible.
As far as I understand you assume for both surrounding induction
variables and parameters that their lb/ub values are the maximal/minimal
possible values in their types. This is not incorrect, however I believe
the constraints in Cloog may provide us with more information,
especially if the context contains constraints on the parameters.
My dream would be to enhance CLooG such that it can provide information
about the minimal an maximal value of each clast (sub)expression.
What types would you get for this code (i,j,k,m, n)?
for (i = 0 ; i < 2; i++)
for (j = i ; j < i + 1; j++)
for (k = j ; k < j + 1; k++)
for (m = k ; m < k + 1; m++)
for (n = m ; n < m + 1; n++)
A[0] += A[n];
I am a little bit afraid that we will increase the type size by an order
of magnitude (or at least one bit) for each nesting level.
Cheers
Tobi
