Hello Eric, this is in regards to your HAVE_window_save code in
var-tracking.c and elsewhere added for PR target/48220.
I'm trying to fix all of the guality failures on sparc and this issue
below is the first one I was able to comprehend.
All of this special register window debugging handling in
var-tracking.c can get tripped up any time we have a leaf function, in
fact I would venture that most if not all of the guality failures on
sparc are directly or indirectly related to this issue.
A good example is pr54200.c, where for function foo:
int __attribute__((noinline,noclone))
foo (int z, int x, int b)
{
if (x == 1)
{
bar ();
return z;
}
else
{
int a = (x + z) + b;
return a; /* { dg-final { gdb-test 20 "z" "3" } } */
}
}
with -O1 and higher we end up with a leaf function here. And incoming
argument register %o0 is used for computing the function's return
value. But var-tracking.c doesn't see these modifications at all.
The reason is that the window tracking code converts the incoming
arguments %iN registers into the outgoing %oN registers.
But this is not the right thing to do because all of the RTL being
inspected has not had leaf register remapping applied to it yet.
So var-tracking.c sees modifications of %i0 in the RTL but doesn't
grok that this is a modification of incoming argument 'z' because it
thinks that 'z' lives in %o0.
Leaf register remapping of the RTL stream is only done as the very
last step in final.c
And when debugging information is emitted, the debugging backends
perform the leaf register remapping manually so that the emitted
debugging regno references match what final.c is going to emit.
This essentially means every other part of the compiler should look at
the RTL and incoming arguments unmolested.
As a quick check I found that if I just remove all of the
HAVE_window_save code in var-tracking.c, the pr54200.c test case
passes at all optimization levels.
Of course there is more to it than this, looking quickly at the
var-tracking rtl dump, it seems to now think in this test case that
the incoming arguments live in both %oN and %iN. I would need to
dig more deeply to figure out why that's happening.
The only other alternative I can see would be to get everything in
var-tracking.c and the other subsystems it uses to do leaf register
remapping, but that seems completely like the wrong way to handle
this.
