public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* Register Spilling
       [not found] <1071059259.17010.ezmlm@gcc.gnu.org>
@ 2003-12-10 12:44 ` Umar Janjua
  2003-12-10 14:58   ` Ian Lance Taylor
  0 siblings, 1 reply; 4+ messages in thread
From: Umar Janjua @ 2003-12-10 12:44 UTC (permalink / raw)
  To: gcc-help

During register allocation , when certain virtual registers are decided to be 
spilled to memory, is there a specific scheme/strategy on the basis of which 
the spilled values are laid out on memory.

regards,

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Register Spilling
  2003-12-10 12:44 ` Register Spilling Umar Janjua
@ 2003-12-10 14:58   ` Ian Lance Taylor
  2003-12-10 15:16     ` Umar Janjua
  0 siblings, 1 reply; 4+ messages in thread
From: Ian Lance Taylor @ 2003-12-10 14:58 UTC (permalink / raw)
  To: Umar Janjua; +Cc: gcc-help

Umar Janjua <Umar.Janjua@cl.cam.ac.uk> writes:

> During register allocation , when certain virtual registers are decided to be 
> spilled to memory, is there a specific scheme/strategy on the basis of which 
> the spilled values are laid out on memory.

Well, yes and no.  The spilled values are put into the stack frame.
The space is allocated by calls to assign_stack_local().  But there is
no predictable ordering of the spilled pseudo-registers, if that is
what you mean.  The registers are spilled as needed as the compiler
works through the instructions.

Ian

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Register Spilling
  2003-12-10 14:58   ` Ian Lance Taylor
@ 2003-12-10 15:16     ` Umar Janjua
  2003-12-10 22:55       ` Falk Hueffner
  0 siblings, 1 reply; 4+ messages in thread
From: Umar Janjua @ 2003-12-10 15:16 UTC (permalink / raw)
  To: Ian Lance Taylor; +Cc: gcc-help

Well, if that is the case, then , how advantageous would be considering cache 
locality for such register spilled values, so that instructions that require 
spilled values do not cause cache miss.
Does the famous register allocation by graph coloring algorithm takes care of 
cache locality for spilled values.

regards



Umar Janjua <Umar.Janjua@cl.cam.ac.uk> writes:

> During register allocation , when certain virtual registers are decided to be 
> spilled to memory, is there a specific scheme/strategy on the basis of which 
> the spilled values are laid out on memory.

Well, yes and no.  The spilled values are put into the stack frame.
The space is allocated by calls to assign_stack_local().  But there is
no predictable ordering of the spilled pseudo-registers, if that is
what you mean.  The registers are spilled as needed as the compiler
works through the instructions.



^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: Register Spilling
  2003-12-10 15:16     ` Umar Janjua
@ 2003-12-10 22:55       ` Falk Hueffner
  0 siblings, 0 replies; 4+ messages in thread
From: Falk Hueffner @ 2003-12-10 22:55 UTC (permalink / raw)
  To: Umar Janjua; +Cc: gcc-help

Umar Janjua <Umar.Janjua@cl.cam.ac.uk> writes:

> Well, if that is the case, then , how advantageous would be
> considering cache locality for such register spilled values, so that
> instructions that require spilled values do not cause cache miss.

Most stack frames easily fit into L1, so probably not a lot. There has
been some work on this motivated by other things, though; see "Optimal
Stack Slot Assignment in GCC" by Naveen Sharma and Sanjiv Kumar Gupta
in the GCC summit proceedings
(http://www.linux.org.uk/~ajh/gcc/gccsummit-2003-proceedings.pdf)

-- 
	Falk

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2003-12-10 22:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <1071059259.17010.ezmlm@gcc.gnu.org>
2003-12-10 12:44 ` Register Spilling Umar Janjua
2003-12-10 14:58   ` Ian Lance Taylor
2003-12-10 15:16     ` Umar Janjua
2003-12-10 22:55       ` Falk Hueffner

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).