This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [mips] fix $gp restore bug
Maciej W. Rozycki writes:
> On Tue, 3 Mar 2009, Adam Nemet wrote:
> > Yes but what if it isn't set up in the prologue. Do you always force the
> > allocation of the GOT pointer even if it won't be used most likely just
> > because there is a branch? If not then you need a way of loading a
> > destination address into $1, which as it seems requires another temporary with
> > the new ABIs lacking (D)ADDIUPC.
>
> You can use $1 as a temporary GOT pointer with new ABIs as they do not
> require $gp to be used. The -mxgot case does require another register
> though.
A sample assembly sequence would help here. It seems to me that you need two
values to be live in registers at the same time to compute the function
address: the got pointer and the got offset or if computing with the
PC-relative sequence: the pc and the pc-relative offset. And of course we
only have one scratch register. (That is why the PC-addition would help: you
have the PC as an implicit operand ready.)
> I don't think (D)ADDIUPC would actually be of any help here -- the 16-bit
> immediate would not cover a range wider than the branch displacement
> already does. I could imagine a "fix" where the addend would be shifted
> left by a few bits (the result could be masked to maintain some
> reasonable alignment), but that would only push the limit a little bit
> further, and then at a cost.
No, I actually meant DADDUPC:
lui $1,%hi(target-1f)
1:
(d)addiu $1,$1,%lo(target-1b)
(d)addupc $1,$1
jr $1
> I found the limitation of GCC that jumps cannot use a scratch register
> painful in the past already; my understanding is jumps are processed too
> late in the game for new register allocations to be possible (and the
> process would have to be iterative), correct?
Yes if the scratch is only needed conditionally depending on the "final" code
layout you need to preallocate the scratch register even though you might not
use it at the end.
Adam