------- 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" <[EMAIL PROTECTED]> 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
