Re: Unrevied patches^3

[Geoff Keating <geoffk at geoffk dot org>]

> From: Richard Sandiford <rsandifo@redhat.com>
> Date: 20 Oct 2003 08:34:03 +0100

> > 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.)
> 
> The problem with this is that small data accesses are possible in
> n32/n64 PIC, in which $gp is set up by the callee.  So if we used a
> plain symbol_ref, we'd have to put back various scheduling barriers in
> the prologue and epilogue (barriers that we used to have, but could be
> removed after the rewrite).  That's likely to pessimise small functions.

In that case, the right thing to do is this.  In the prologue, you
have:

(set (reg $gp) (...)) (REG_EQUAL (symbol_ref ("small_data")))
[or whatever the symbol is named.]

Then, in the RTL of the routine, you have

(set (reg ...)
 (plus (reg $gp) 
  (const (minus (symbol_ref ("x"), symbol_ref ("small_data"))))))

This is what rs6000 does in, I think, -fPIC mode on SVR4.

> Besides, MIPS isn't the first port to use $gp as the high part of a
> LO_SUM.  The idea was borrowed from the alpha port and IMO it makes
> sense.  (lo_sum (reg X) (symbol_ref "small_data_symbol")) is written
> out as:
> 
>     %gp_rel(X)
> 
> and $gp really _is_ the high part of this value.

Right, but on MIPS you're just using LO_SUM as, basically, UNSPEC; and
then you're trying to work around the use of UNSPEC by hacking the
middle-end.  Instead you should represent these operations as what
they really are, and then you will not need to hack the middle-end.

-- 
- Geoffrey Keating <geoffk@geoffk.org>