Thanks.
To note: there's one thing about splitting that is a key part of the
allocator core: losing ranges have to be changed somehow to progress. There
are 2 possible changes: spill the whole range or split and re-schedule the
resulting pieces. Some ranges can't be spilled, so some splitting
Sounds reasonable to me. The splitting policy and placement of spill code
is somewhat orthogonal to the allocator core, but the main point on which
we suck. I discussed with Mircea pre-splitting the ranges around calls and
in differed code before building intervals. That could potentially benefit
Hey Mircea,
I think I just came up with a good criteria for a new register allocator:
It should be possible to add stack checks to every loop in asm.js code
without noticable performance impact.
Currently we skip the stack checks for asm.js functions because the
spilling around the stack check
Quick DBC...
https://codereview.chromium.org/1157663007/diff/160001/src/compiler/register-allocator.h
File src/compiler/register-allocator.h (right):
https://codereview.chromium.org/1157663007/diff/160001/src/compiler/register-allocator.h#newcode969
src/compiler/register-allocator.h:969: if
Oh, nice! Thanks.
The openness just means that a_end == b_start || b_end == a_start doesn't
mean intersection. So we just need strict inequality in your expression,
that's all.
On Fri, Jun 12, 2015 at 12:36 AM svenpa...@chromium.org wrote:
Quick DBC...
Thanks, indeed, while the code bring-in will change a bunch of things, I
can still use the feedback.
On Fri, Jun 12, 2015 at 8:20 AM Mircea Trofin mtro...@chromium.org wrote:
Oh, nice! Thanks.
The openness just means that a_end == b_start || b_end == a_start doesn't
mean intersection. So we
I believe there may be a difference in assumptions/premises. Let's see if
we can tease those apart. I also realize I am to blame for not having had
stated what my plans here were - which is quite possibly the reason for
these differences :)
When we started this effort, we had no data to indicate
Some comments I accumulated yesterday. I realize that a lot of this code
will be
changed, so these are more like suggestions for how the new code should
like.
https://codereview.chromium.org/1157663007/diff/80001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc
Thanks for the feedback - updated.
https://codereview.chromium.org/1157663007/diff/120001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/120001/src/compiler/register-allocator.cc#newcode354
This is actually a big CL, which I'm not sure we can get into landable state
soonish. I suspect that we could proceed a lot faster if we split the work
into
manageable parts, something along these lines:
1.) Do the minimal amount of work required to make the greedy allocator
bot
green
On 2015/06/11 08:15:43, Benedikt Meurer wrote:
This is actually a big CL, which I'm not sure we can get into landable
state
soonish. I suspect that we could proceed a lot faster if we split the work
into
manageable parts, something along these lines:
1.) Do the minimal amount of work
Indeed... looking at it closely, this must have been remnants from
something I tried and then changed, but clearly not completely. Removed
that entire idea (the enum, the loop, and the state moving function).
Thanks!
On Tue, Jun 9, 2015 at 10:59 PM ja...@chromium.org wrote:
https://codereview.chromium.org/1157663007/
--
--
v8-dev mailing list
v8-dev@googlegroups.com
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
First round of comments.
https://codereview.chromium.org/1157663007/diff/120001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/120001/src/compiler/register-allocator.cc#newcode127
Next batch of comments.
https://codereview.chromium.org/1157663007/diff/40001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/40001/src/compiler/register-allocator.cc#newcode888
https://codereview.chromium.org/1157663007/diff/40001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/40001/src/compiler/register-allocator.cc#newcode888
src/compiler/register-allocator.cc:888: DCHECK_NE(0U,
https://codereview.chromium.org/1157663007/diff/80001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/80001/src/compiler/register-allocator.cc#newcode3227
src/compiler/register-allocator.cc:3227: Next(state)) {
Some very-surface-level comments.
https://codereview.chromium.org/1157663007/diff/40001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/40001/src/compiler/register-allocator.cc#newcode2101
Incorporated feedback, and also retracted the cosmetic formatting in both
disassembler.cc and scheduler.cc, which fit better in a different CL (plus,
the
dec-hex change should probably hide behind a flag, and definitely extend to
other places offsets are used, e.g. jumps)
Another batch of comments.
https://codereview.chromium.org/1157663007/diff/20001/src/compiler/register-allocator.cc
File src/compiler/register-allocator.cc (right):
https://codereview.chromium.org/1157663007/diff/20001/src/compiler/register-allocator.cc#newcode3477
First batch of comments.
https://codereview.chromium.org/1157663007/diff/20001/src/compiler/register-allocator.h
File src/compiler/register-allocator.h (right):
https://codereview.chromium.org/1157663007/diff/20001/src/compiler/register-allocator.h#newcode485
https://codereview.chromium.org/1157663007/diff/20001/src/compiler/register-allocator.h
File src/compiler/register-allocator.h (right):
https://codereview.chromium.org/1157663007/diff/20001/src/compiler/register-allocator.h#newcode485
src/compiler/register-allocator.h:485: float weight_;
On
22 matches
Mail list logo
