This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> 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

2) making get_computation_aff work in double_ints instead of

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]