This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: m68k reloc types


On Wed, Aug 18, 2004 at 01:47:59AM +0200, Andreas Schwab wrote:
> > 	(set (reg:SI tmp) (symbol_ref:SI "x"))
> > 	(set (mem:SI (reg:SI tmp)) ...)
> 
> Actually it would be nice to be able to expose the full details of PIC
> addressing in rtl, so that you can decide case by case whether to use
> PC-relative or GOT relative.

You do not, however, really want to expose the pc for pc-relative.
You'll confuse the middle-end.  I personally would just leave the
symbol_ref bare and know what it really means based on compiler
switches.  But if you insist, you can do

	(const (unspec [(symbol_ref "x")] PC_REL))

to make things explicit.  But...

> One nice thing about the PIC implementation
> on the m68k is that you can actually chose the PIC register freely, you
> don't have to use a fixed or even a call-saved register.  So for example
> in a leaf function you could just use a scratch register for it.

See ix86_select_alt_pic_regnum.  Do the same thing for m68k.
You do, however, still have to leave one register fixed so
that you have a backup in case no scratch is available.

If you want to be exceedingly clever, with -fpic you count
the number of symbolic references that make it to reload,
and choose between pc-relative or pic-register-relative then.
The lea to load the pic-register is 3 words long, so you'd
need at least 3 symbolic references to make the pic-register
pay off.  Two more if creating a pic register causes you to
spill the first or second register in the frame.  (Well, I
guess that's for 68020+ only; coldfire never gets a size
advantage for using pc-relative over 16-bit gp-relative).

With -fPIC, and without adding a new gp-relative relocation,
I see no advantage to using a pic-register at any time.

	lea	(x, %pc), %a0			# 68020+

	movel	#x-.-2, %a0			# 68000, Coldfire
	lea	(-6, %pc, %a0), %a0

The alternative is

	movel	(x@GOT:l, %a5), %a0		# 68020+

	movel	#x@GOT, %a0			# 68000, Coldfire
	movel	(%a5, %a0), %a0

which is the same size but adds a memory reference.

Both alpha and ia64 are examples of targets that do not expose
any PIC related specifics until after reload.  I'd do the same
if I were going to rewrite m68k symbol handling.  Particularly
if you're going to choose between pcrel or gprel late in the game.


r~


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]