Save memory with ppc elf shared libraries.

[Geoff Keating]

> cc: egcs-patches@cygnus.com
> Reply-To: law@cygnus.com
> Date: Tue, 08 Dec 1998 00:10:24 -0700
> From: Jeffrey A Law <law@hurl.cygnus.com>
> 
> 
>   In message < 199812041150.WAA12568@geoffk.wattle.id.au >you write:
>   > 
>   > The attached small patch lets egcs put read-only data in .rodata when
>   > building PIC code under powerpc linux.  This significantly reduces the
>   > memory footprint of the OS.
>   > 
>   > I have been running a similar patch for some time now, and egcs never
>   > put an initialized pointer in .rodata.  I think what happened is that
>   > this was copied across from eabi.h at some point and then someone did
>   > a search-and-replace for 'TARGET_RELOCATABLE' with
>   > '(TARGET_RELOCATABLE || flag_pic)' when flag_pic was implemented for
>   > ppc.
>   > 
>   > -- 
>   > Geoffrey Keating <geoffk@ozemail.com.au>
>   > 
>   > ===File ~/patches/egcs-8.diff===============================
>   > 1998-12-04  Geoff Keating  <geoffk@ozemail.com.au>
>   > 
>   > 	* config/rs6000/sysv4.h (CONST_SECTION_ASM_OP): Use .rodata even
>   > 	when `flag_pic'.  Initialised pointers are put in .data already by
>   > 	rs6000_select_section in config/rs6000/rs6000.c when `flag_pic'.
> I'm not entirely sure this is safe.
> 
> At least on other ports, symbolic addresses can be passed to SELECT_RTX_SECTION
> if reload has to force a symbolic address into memory for one reason or
> another.
> 
> It looks like ASM_OUTPUT_SPECIAL_POOL_ENTRY_P would catch this and force items
> which were initialized via a symbolic addresses into toc_section.  However, it
> does not do this is TARGET_TOC is zero.  Instead such variables would end up
> in the const_section which would lose.
> 
> Can TARGET_TOC ever be zero in sysv4 configurations?  If so, then you'll need
> to change select_rtx_section slightly to make sure symbolic initializers are
> placed into the data section for PIC code.

The actual condition, from sysv.h, is as follows:

#define TARGET_TOC              ((target_flags & MASK_64BIT)            \
                                 || ((target_flags & (MASK_RELOCATABLE  \
                                                      | MASK_MINIMAL_TOC)) \
                                     && flag_pic > 1)                   \
                                 || DEFAULT_ABI == ABI_AIX              \
                                 || DEFAULT_ABI == ABI_NT)

and in SUBTARGET_OVERRIDE_OPTIONS, there is:

  /* Treat -fPIC the same as -mrelocatable */                           \
  if (flag_pic > 1)                                                     \
    target_flags |= MASK_RELOCATABLE | MASK_MINIMAL_TOC | MASK_NO_FP_IN_TOC; \
  else if (TARGET_RELOCATABLE)                                          \
    flag_pic = 2;                                                       \

when flag_pic == 0, of course it's safe to put anything in the const
section.  The TARGET_RELOCATABLE case is left alone by my patch, so
that's OK too.

So the only case to worry about is when flag_pic == 1.

Now, in this case, most symbolic addresses are already in memory.  But
addresses of the form

(const (plus (sym_ref "foo") 10))

are not put in the GOT.

Can reload ever try to put this in memory?  Even if it can load
(sym_ref "foo") from memory and perform the addition in the same
register it performed the load from?

[Of course, reload can't ever try the same thing if the second operand
isn't a const_int, because the linker can't handle it.]

LEGITIMIZE_ADDRESS seems to always do such computations in registers.

Perhaps, though, it might be best to change rs6000_select_rtx_section
to be on the safe side.  Something like:

if (flag_pic == 1 &&
    (GET_CODE (x) == SYMBOL_REF
     || (GET_CODE (x) == CONST && GET_CODE (XEXP (x, 0)) == PLUS
         && GET_CODE (XEXP (XEXP (x, 0), 0)) == SYMBOL_REF)
     || GET_CODE (x) == LABEL_REF))
  data_section ();
else if (ASM_OUTPUT_SPECIAL_POOL_ENTRY_P (x))
  toc_section ();
else
  const_section ();

But I can't test this, because I have no examples of a case when it
might ever be used...

There really should be a macro to mean "includes symbol reference",
that is the condition above.

-- 
Geoffrey Keating <geoffk@ozemail.com.au>