This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

Re: literal pool support


It's been rumoured that David Edelsohn said:
> 
> >>>>> Richard Henderson writes:
> 
> Richard> If you don't keep the literals on the page, you burn two registers
> Richard> instead of one.

Right.

> 	One probably needs to set up a data area, so one can place the
> literals in the normal data area. 

But that still requires an extra register to be burned.  I have started
thinking/working on patches that will move the literal pool out of the 
text section.  But its a big task since I want to do it without blowing 
another register; that in turn means more cleanup in all sorts of nooks 
& cranies.
 
> On MVS and VM, at least, the code
> segment is not mapped read-only, so one has not gained any read-only data
> benefit from co-locating the literals with the code.

But literals are not ever written to, so that's not an issue (with
the possible exception of shared/dynamic-load, pic code, which I am still
trying to wrap my head around.  The lit-pool-in-text-section does seem
to pose a problem for shared/dynamic link).

> 	The next generation S/390 architecture has PC-relative
> addressing.  When GCC utilizes those instructions there will be no reason
> to maintain a base register for local branch addressibility.  

There are users out there who use gcc on MVS today; can't leave them hi-n-dry.
It'll take 5-10 years for such equipment to go obsolete & be replaced by the 
new h/w and even then there is the prospect of maintaining old code.  Besides,
what we have today works, why break it?

> If one avoids the literal pool now, then recovering the
> extra GPR is much easier later.

I will show my ignoracnce: how can I avoid a literal pool? I agree it can be 
moved out of the text section, but avoided, this I don't understand. If you are
thinking 'toc', then let me remind out that it would have to be multiple 12-bit 
tocs cause of 12-bit addressing.  Also, the 390, unlike the riscs, has a 4-cycle
penalty between load & use of a base register.  (I don't entirely understand,
but somehow that's the price paid the piper for no-penalty branches, or so
goes the disinformation in my possesion).  So basically, you want to avoid reloading
the base register if at all possible, which seems to rule out a toc.

--linas


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