[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter

["olegendo at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162

Oleg Endo <olegendo at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu.org

--- Comment #3 from Oleg Endo <olegendo at gcc dot gnu.org> 2012-11-02 10:07:26 UTC ---
(In reply to comment #2)
> >For example, passing a virtual address 0x00001000 and c = 0x80000000 to the
> function should actually run over the address range 0x00001000 .. 0x80001000,
> 
> 
> No it runs over the address range 0x00001000 .. -1 and more as 0x80000000 * 4
> wraps/overflows.  If x was char* then I would say there is a bug but this is
> int* which has a size of 4.

Ugh, sorry for the mess up.  Of course you're right.
I guess that the pointer wrap-around would fall into "undefined behavior"
category.  If so, then the loop counter adjustment could be left out entirely,
couldn't it?
My point is that the loop counter adjustment can become quite bloaty on SH:

struct X
{
  int a, b, c, d, e;
};

int test (X* x, unsigned int c)
{
  int s = 0;
  unsigned int i;
  for (i = 0; i < c; ++i)
    s += x[i].b;
  return s;
}

results in:
        tst     r5,r5
        bt/s    .L4
        mov     r5,r1
        shll2   r1
        add     r5,r1
        mov.l   .L9,r2
        shll2   r1
        add     #-20,r1
        shlr2   r1
        mul.l   r2,r1
        mov.l   .L10,r2
        add     #4,r4
        mov     #0,r0
        sts     macl,r1
        and     r2,r1
        add     #1,r1
.L3:
        mov.l   @r4,r2
        dt      r1
        add     #20,r4
        bf/s    .L3
        add     r2,r0
        rts
        nop
.L4:
        rts
        mov     #0,r0
.L11:
        .align 2
.L9:
        .long   214748365
.L10:
        .long   1073741823