https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.cc#newcode408
src/compiler/register-allocator.cc:408: // the range and control flow
connection mechanism instead.
On 2015/08/06 12:28:42, Jarin wrote:
Please elaborate on how this uses the control flow connection
mechanism.
This incremental build-up of various moves is in my opinion the worst
part of
the register allocator (in terms of understandability and
maintainability), and
this CL makes it worse. It should be explained in the comments.
Added comments. I think clarifying the role of each stage should make
comprehension a bit easier. I'm not sure yet how we can improve the
current design.
One additional aid may be making the marking of deferred block-only
ranges a phase in itself - a post-process ranges phase, if you will. In
the spirit of incremental changes, though, I'll do that separately.
https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h
File src/compiler/register-allocator.h (right):
https://codereview.chromium.org/1271703002/diff/80001/src/compiler/register-allocator.h#newcode417
src/compiler/register-allocator.h:417: // in which it may be worse to
spill in it.
On 2015/08/06 12:28:42, Jarin wrote:
The comment seems to be out of date (it refers to the ranges with just
one
spilled child).
Done.
https://codereview.chromium.org/1271703002/
--
--
v8-dev mailing list
[email protected]
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
