[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162 --- Comment #4 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-03 12:19:28 UTC --- (In reply to comment #3) I've created a new PR 55190 for this.
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
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 0x1000 and c = 0x8000 to the
function should actually run over the address range 0x1000 .. 0x80001000,
No it runs over the address range 0x1000 .. -1 and more as 0x8000 * 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
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162
--- Comment #1 from Oleg Endo olegendo at gcc dot gnu.org 2012-11-01 10:11:46
UTC ---
(In reply to comment #0)
The same could be done on SH, too (comparing against the end address instead
of
using a loop counter), but it would add a loop setup overhead. In the optimal
case the above function would result in the following SH code:
tst r5,r5
bt/s.L6
mov #0,r0
.L3:
mov.l @r4+,r1
dt r5
bf/s.L3
add r1,r0
.L6:
rts
nop
... which is the case if '*x++' is used instead of 'x[i]':
int test (int* x, unsigned int c)
{
int s = 0;
unsigned int i;
for (i = 0; i c; ++i)
s += *x++;
return s;
}
[Bug tree-optimization/55162] Loop ivopts cuts off top bits of loop counter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55162 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-11-02 04:08:25 UTC --- For example, passing a virtual address 0x1000 and c = 0x8000 to the function should actually run over the address range 0x1000 .. 0x80001000, No it runs over the address range 0x1000 .. -1 and more as 0x8000 * 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.
