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 wrote:
> From: Jeff Law
> Subject: Re: Does IRA support spilling to registers instead of stack?
> To: "Vladimir Makarov"
> Cc: dpadgett_mail-...@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-...@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-
>
