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]
Other format: [Raw text]

Re: Does IRA support spilling to registers instead of stack?


Thanks. Yes, these registers for the target, which is MIPS16e, cannot be used in arithmetic, logical, etc. They can only be used in copy instructions.  More specifically, the registers I'm referring to are the general-purpose MIPS32 registers, such as t0 and s2, that are not part of the 8 register subset usable in operations involving arithmetic, logical, etc for MIPS16e.

This is actually part of the problem since the current register description for MIPS16e I don't believe properly reflects that these registers are not usable in operations involving arithmetic, logical, etc.  As a result, IRA is misled in its work and reload has to come along and introduce copies to move values to and from these registers into the 8 register subset so that arithmetic, logical, etc operations can be done.

Don

--- On Tue, 7/19/11, Jeff Law <law@redhat.com> wrote:

> From: Jeff Law <law@redhat.com>
> Subject: Re: Does IRA support spilling to registers instead of stack?
> To: "Vladimir Makarov" <vmakarov@redhat.com>
> Cc: dpadgett_mail-000@yahoo.com, gcc@gcc.gnu.org
> Date: Tuesday, July 19, 2011, 10:21 AM
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/19/11 07:33, Vladimir Makarov wrote:
> > On 07/18/2011 05:20 PM, dpadgett_mail-000@yahoo.com
> wrote:
> >> Hello,
> >>
> >> Does gcc IRA provide a mechanism to support
> spilling to registers
> >> instead of the stack?? For the particular
> target I'm looking at, there
> >> are some non-general-purpose registers that can be
> copied to and from
> >> more quickly than the stack, so would be
> preferable to use as a form
> >> of shareable spill slot in some cases.? One
> limitation, which is
> >> perhaps a significant one, is that these registers
> are not callee
> >> save, so one would only want to save to and
> restore from them when
> >> there is no intervening function call. If there is
> no current support
> >> for such a mechanism, any opinions on the value
> and practicality of
> >> adding one would be much appreciated.
> >>
> >> Thanks, Don
> > It might work for new IRA without cover classes.
> > 
> > Pseudos will have classes containing usual registers
> and these special
> > registers because they are really less costly than
> memory.? If a pseudo
> > crosses a call, the special registers could be more
> costly than memory.
> > 
> > All you need is to define the right costs for register
> and memory move
> > cost hooks to achieve better costs for regular
> registers, worse costs
> > for the special registers, and the worst cost for
> memory.? If the pseudo
> > intersects the call, the worst cost should be for the
> special
> > registers.? It can be achieved by right
> definition of move cost between
> > special registers and memory.
> Note that if these registers are not available for other
> operations such
> as arithmetic, logicals, etc, then they won't be used for
> spilling where
> the range of the pseudo contains such operations.? So
> merely getting the
> costs right is only part of the solution, the other part is
> to
> intelligently split the range of the pseudo.
> 
> Jeff
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJOJaDjAAoJEBRtltQi2kC7jtMH/R7BpVBCPbbriKeqRc/NKMEr
> ZBd2tZcLLmfc61nkb0iNIGDF9mZa+uC/GOa09dmsriFooVl/4WaY5vT68UbV4zsG
> zlHSb87wk9vJUb9x3Dve2RwRF4GQH3cO6SUxMWJZDsppnd8tF+xuO0rKAexyxLHF
> uJ2R11hhmKMlK9P5rWEpqsVa/HZOnmVjFawuLhj0qEQew591rPuj9ACB28niXUiE
> 0P+P6MFvkWpSEA65YGlRyP3epczX//0jSFZQ+N/WRZJH0Ev0qeawzHj/X+SMP4W1
> nTGFhf1Wad7IeXTZgUDH7cN7Xdvojq6b+KvFASBxwJGpH3+/QccWSFsgGLvvmBs=
> =jMEL
> -----END PGP SIGNATURE-----
>


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