Re: [PATCH, ivopts] Handle type-converted IVs better

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> In the loop below before the store, the value is casted to int.
> ivopts decides that it is simpler to formulate that use in terms of a
> new induction variable {0, +, 1} instead of using the candidate
> derived from data_offset.
> 
>   long last_data_offset;
>   int store;
>   char *data;
>   
>   f ()
>   {
>   
>     long data_offset = last_data_offset;
>     char *p;
>   
>     for (p = data; *p; p++)
>       {
>         data_offset++;
>         g (data_offset);
>         store = data_offset + 1;
>       }
>   }
> 
> 
> This is because when it estimates the cost of the data_offset
> candidate it works with this over-complicated expression:
> 
>   (int) ((unsigned int) (data_offset_5 + 2)
>          - (unsigned int) data_offset_5
>          + (unsigned int) data_offset_11 - 1)
> 
> Instead of trying to fold this which I am not even sure is valid in
> the generic case (can we remove overflows?)

under most circumstances, the answer is yes (as long as you do not
create new overflowing expressions);  the only case when the answer
might be no is with -ftrapv, but that probably should not apply for
expressions generated by compiler anyway.

> I took a different approach.
>
> When a use of an IV is expressed using another candidate I check
> whether the IV in question is a type-converted version of a different
> IV.  If yes then I try to express the candidate from the original IV
> and type-cast the result.

I am not quite sure that I like this approach too much.  As far as I
understand the problem, you should be able to get the same effect by:

1) using the following patch (that enables you to use affine
   combinations even with types whose values do not fit in
   HOST_WIDE_INT)
   http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00345.html,
   and

2) making get_computation_aff work in double_ints instead of
   HOST_WIDE_INTs.

With this cleanup (and possibly a minor change similar to your
aff_combination_convert), you should be able to get the required folding
easily,  without need to handle the "type-converted version of a
different IV" special case.

Zdenek