This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, ivopts] Handle type-converted IVs better
Roger Sayle writes:
> I'll consider it for mainline, if you can describe/provide a testcase
> where we've regressed and that is restored by your patch.
Sure.
This is the testcase from my original email:
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;
}
}
The MIPS64 assembly with 3.4.4 for the loop is:
$L9:
jal g
daddiu $16,$16,1
daddiu $17,$17,1
sw $16,%gp_rel(store)($28)
lb $2,0($17)
bne $2,$0,$L9
move $4,$16
Nice. Mainline without the patch looks like this:
$L4:
daddiu $16,$16,1
move $4,$16
jal g
daddiu $17,$17,1
* sll $3,$18,0
* addu $3,$3,$19
sw $3,%gp_rel(store)($28)
lb $2,0($17)
bne $2,$0,$L4
* daddiu $18,$18,1
Marked are the unnecessary instructions wasted on maintaining the
additional IV.
Mainline with the patch is still not perfect but better:
$L9:
move $4,$16
jal g
daddiu $17,$17,1
* sll $3,$16,0
* addiu $3,$3,1
sw $3,%gp_rel(store)($28)
lb $2,0($17)
bne $2,$0,$L9
daddiu $16,$16,1
Mainline truncates too early which seems like another regression. But
anyway point is that there is no reason to add another induction
variable (additional register, extra instruction to maintain it) since
we can compute the same value using an existing IV.
> If it can be made into a new dejagnu test for the testsuite, even
> better.
No unfortunately, at least not yet. I don't think there is
infrastructure for checking the number of induction variables ivopts
determines. I am planning to do something about this though.
Adam