[Bug target/32406] [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3

[richard at codesourcery dot com]

------- Comment #3 from richard at codesourcery dot com  2007-06-20 12:56 -------
Subject: Re:  [4.3 Regression] MIPS: FAIL in nestfunc-6.c at -O3

"daney at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> writes:
> I don't really like the patch that much though.  It forces $gp to be
> loaded in a nonlocal_goto_receiver, which fixes the bug in cases where
> $gp is needed.  If $gp is not needed, it would be nice not to force it
> to be restored.
>
> In vain I tried to mark $gp as clobbered in hope that it would be
> magically restored if needed.  I guess I need a bit more RTL foo.  If
> there are two function calls in the nonlocal goto target (two uses of
> $gp with a clobber between), the second call has $gp restored.  I
> think there should be a way to make the first use of $gp to cause $gp
> to be restored, but I don't know what it is.

The post-reload splitter converts the unspec_volatile into an ordinary
move.  In theory (TM), if the restore isn't needed, it should get deleted
as dead after that point.

Stepping back, the model here is that anything up to and including the
post-reload splitters can introduce new uses of pic_offset_table_rtx.
(This includes reload, which might need new uses of pic_offset_table_rtx
in order to access the constant pool.  It also includes high/lo_sum
accesses that we previously modelled as being purely symbolic;
this higher-level, register-free form is easier to optimise.)

So we basically consider $gp to be live throughout the function before
the post-reload splitters.  At that point, when using explicit relocs,
every use of $gp becomes explicit, and normal liveness rules apply.
Do you have an example of a function that does need $gp at some point,
but which restores $gp unnecessarily at other points?

I suppose there will be cases where a function with a nonlocal goto
doesn't need $gp at all, but sets $gp up anyway because of the set in
the receiver pattern.  I can think of a way of dealing with that,
but it will mean adding special cases.  I wonder how often it would
trigger.

Richard


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32406