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 15:37:03, Mircea Trofin wrote:
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.
Also, moved the test away from "CommitSpillsAtDefinition", seems like
better code organization.
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.
