mips/debug/reload question (PR 54128)

[Georg-Johann Lay]

Steve Ellcey schrieb:
> 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?

Maybe a wrong use of next_insn instead of next_nonnote_nondebug_insn or
alike?

Johann

> Steve Ellcey
> sellcey@mips.com