This is the mail archive of the gcc@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]

PIC register allocation by reload (Was: Re: egcs-1.2 stuff)


> 
>   In message <199903281412.JAA02308@caip.rutgers.edu>you write:
>   > 	I think we should address the -fpic/-fPIC failures on the sparc. 
>   > This would affect glibc or really any shared library.  IIRC, Dave had a
>   > preliminary fix early last fall around the time we split the 1.1.x
>   > branch.  For some reason it never went in.  (?)
> If it's the problem I think it is then it's unlikely we'll have a general
> solution in time for egcs-1.2. 
> 
> Lazy allocation of the PIC register is a bad bad idea right now.  It's going
> to consistently lose.  If we want this to work 100% reliably for egcs-1.2, then
> the backend is going to need to pre-allocate the register early and take the
> performance hit.  This effects multiple ports that have tried to do lazy
> allocation of the PIC register (for example the ppc).
> 
> Then someone will need to block out some significant time post egcs-1.2 to fix
> the problem correctly.  It's not a simple problem to fix.

I think that, if no PIC register is preallocated and we find during
reload that we need one after all, we should just load it with a secondary
reload (by defining SECONDARY_RELOAD_INPUT_CLASS and reload_in[sd]i
appropriately).
We should check that reload inheritance works for the temporarily
allocated PIC register.  Then we should get actually better code than if
we allocated the PIC register for the entire function.


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