Change the register allocator so that it no longer tracks references...

Change the register allocator so that it no longer tracks references
to the platform-specific reserved registers.  They are always in use
for their intended purpose, cannot appear in the virtual frame, and
can be freely used without allocation in the code generator.


Committed: http://code.google.com/p/v8/source/detail?r=2061

[William Hesse, 2009-05-26 13:33:32]

LGTM.

http://codereview.chromium.org/113837/diff/104/109
File src/ia32/register-allocator-ia32-inl.h (right):

http://codereview.chromium.org/113837/diff/104/109#newcode63
Line 63: }
You could map the codes 0,1,2,3, and 7 to the range 0..4 by
(i + 1) & 7, and back by (i+7) & 7.  Would this be faster than the lookup
tables?

http://codereview.chromium.org/113837/diff/104/121
File src/ia32/virtual-frame-ia32.h (right):

http://codereview.chromium.org/113837/diff/104/121#newcode152
Line 152: // Sync the range of elements in [begin, end] with memory.
I am surprised that there were no uses of this that incorrectly assumed that
elements[end] didn't get synced.
Is this true, and was this always just an incorrect comment
listing the range as not including end?

[Kevin Millikin (Chromium), 2009-05-27 07:43:07]

http://codereview.chromium.org/113837/diff/104/109
File src/ia32/register-allocator-ia32-inl.h (right):

http://codereview.chromium.org/113837/diff/104/109#newcode63
Line 63: }
On 2009/05/26 13:33:32, William Hesse wrote:
> You could map the codes 0,1,2,3, and 7 to the range 0..4 by
> (i + 1) & 7, and back by (i+7) & 7.  Would this be faster than the lookup
> tables?

I'll give it a try.  It has the side effect of allocating in a different order
(changing our bias toward eax into a bias toward edi).

http://codereview.chromium.org/113837/diff/104/121
File src/ia32/virtual-frame-ia32.h (right):

http://codereview.chromium.org/113837/diff/104/121#newcode152
Line 152: // Sync the range of elements in [begin, end] with memory.
On 2009/05/26 13:33:32, William Hesse wrote:
> I am surprised that there were no uses of this that incorrectly assumed that
> elements[end] didn't get synced.
> Is this true, and was this always just an incorrect comment
> listing the range as not including end?

The comment was incorrect.  At some point we changed it to avoid writing +1, but
now I've introduced more call sites where we have to write -1.