http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128
I was wondering if anyone could help me out with a mips target bug
involving debug info and register allocation / reload.
The initial problem was that when bootstrapping on a mips linux
box I got a compare failure with tree-data-ref.o, I have since
cut down tree-data-ref.c to get a smaller preprocessed test case
and reproduced the problem using that input and a non-bootstrapped
mips cross compiler generating big-endian code. The original test
was different when compiled big-endian or little-endian but the
smaller test case only generates different code in big-endian mode.
(This test case is in the bug report 54128)
Looking at that smaller example I can see that compiling with "-O2 -g"
in one case and just "-O2" in the other causes the code generation
to be different in the ira/reload1 phase of the compiler.
In the non-debug case (in analyze_subscript_affine_affine):
addiu $2,$sp,40
sw $2,16($sp)
lw $2,72($sp)
lw $25,%got(compute_overlap_steps_for_affine_univar)($28)
move $5,$3
sw $2,20($sp)
In the debug case:
move $5,$3
lw $3,72($sp)
addiu $2,$sp,40
lw $25,%got(compute_overlap_steps_for_affine_univar)($28)
sw $2,16($sp)
sw $3,20($sp)
When I try tracing through the differences in the two compiles I see
that register $2 is showing up in the used_by_pseudos register set (in
reload1.c) when compiling with "-O2 -g" but not when I use just "-O2",
and I think this is what leads to the different code generation because
one compile uses $2 and the other thinks it is unavailable and goes on
to use $3, but I have not been having any luck in figuring out how or
why $2 is getting put into used_by_pseudos.
I have reproduced this with multiple mips architecture settings, so while
it may be specific to mips it does not seem to be tied to one particular
mips architecture. And while the small test case only shows the failure
in big-endian mode, the original bug was found on a little-endian system.
Any advice or help?