Re: [Bug tree-optimization/22236] [4.1 Regression] wrong code forcasts and scev

[Daniel Berlin <dberlin at dberlin dot org>]

On Tue, 2005-07-26 at 12:10 +0200, Sebastian Pop wrote:
> After inlining, we end up with a loop containing the following code:
> 
>    b.0_3 = (signed char) b_8;
>    D.1621_4 = (int) b.0_3;
>    a_5 = (signed char) D.1621_4;
>    D.1640_6 = (int) a_5;
>    b_7 = D.1640_6 - 127;
>    if (b_7 > 1) goto <L3>; else goto <L9>;
>    
> that is equivalent to:
> 
>    b_7 = ((int) (signed char) (int) (signed char) b_8) - 127;
>    if (b_7 > 1) goto <L3>; else goto <L9>;
> 
> with b_8 = (unsigned char) {1, +, 1}
> 
>    b_7 = ((int) (signed char) (int) (signed char) {(uchar)1, +, (uchar)1}) - 127;
>    if (b_7 > 1) goto <L3>; else goto <L9>;
> 
> A sequence of unsigned char 1, 2, ..., 255 has to be converted to
> signed char that would wrap with -fwrapv: 1, 2, ..., 127, -128, ...
> So here is a patch that keeps the cast if the sequence wraps. 

You mean keep the cast at all, or keep it in the evolution describing
the number of iterations in the loop.

If you mean keep it in the number of iterations of the loop, that seems
wrong:


Let's look at the case again
void abort(void);

static inline void
foo (signed char a)
{
  int b = a - 0x7F;
  if (b > 1)
    abort();
}

int main()
{
  unsigned char b;
  for(b = 0;b <0xFF;b++)
   foo (b);
}

Note that foo doesn't *actually* change the value of the passed in parameter.
The loop still iterates 0xFF times.

Why is the cast affecting the number of iterations in the loop at all?
We should still calculate the number of iterations to be 255 in any case.

also,

in *all* of the vectorizer testcases, number_of_iterations_in_loop should be determined to be "n", an int.

The code in those cases provably doesn't wrap (signed integer arithmetic doesn't wrap without -fwrapv), 
So why do we think it should wrap, when it's not casted at all?