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?


-----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]