This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Unrevied patches^3
Richard Sandiford <rsandifo@redhat.com> writes:
> Geoff Keating <geoffk@geoffk.org> writes:
> > This patch isn't right. What is the MIPS port doing that it has a
> > LO_SUM without a corresponding HIGH? Why can it not represent this
> > using PLUS, or some other arithmetic operation, instead?
>
> I don't understand. The LO_SUM does have a high part, but it isn't
> always represented as a HIGH:
>
> - If the symbol refers to small data, the high part is $gp
> (this is like what the alpha port does, except the alpha
> port only uses it after reload).
>
> - When generating PIC, the high part is a load from the GOT.
> It's represented as such even before reload (which this makes
> various things easier).
>
> Are you saying that the first operand to a LO_SUM must be provided
> specifically by a HIGH, rather than some other "more specific"
> rtx that evaluates to the same thing?
You should probably look up the documentation for LO_SUM and HIGH.
It doesn't have to be represented as a HIGH, it is usually a register.
You have RTL like:
(set (reg $gp) (high (symbol_ref "foo")))
(set ... (lo_sum (reg $gp) (symbol_ref "foo")))
but the middle-end has no problem with this.
I'm not completely sure how MIPS small data works, but I thought it
didn't do this. I thought that the point of using small data was that
the offset to it did not have a high part (it fits in 16 signed bits,
thus "small"), and that the register used as a base was fixed. In
that case, I would recommend simply writing
(set ... (symbol_ref "foo"))
and leaving $gp out of it. (This is what rs6000 does, and HIGH/LO_SUM
was originally invented for rs6000.)
I don't understand what you mean by "the high part is a load from the
GOT". If you can load the high part from the GOT, why don't you just
load the whole address from there?
--
- Geoffrey Keating <geoffk@geoffk.org>