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 needs to happen. My plan is to consider as "core" the first splittable position before or after a use position, following that heuristics be added before that.
On Tue, Jun 16, 2015 at 13:55 Ben L. Titzer <[email protected]> wrote: > 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 > either allocator. > > On Mon, Jun 15, 2015 at 9:05 PM, Benedikt Meurer <[email protected]> > wrote: > >> 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 would completely ruin the performance of >> all loops (see AstGraphBuilder::VisitIterationBody in ast-graph-builder.cc >> for details). I guess once we're able to turn on those checks (which will >> also make asm.js code interruptible/debuggable), we probably reached the >> first important milestone for a new register allocator. >> >> greets, >> Benedikt >> >> On Fri, Jun 12, 2015 at 5:21 PM, Mircea Trofin <[email protected]> >> wrote: >> >>> 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 <[email protected]> >>> wrote: >>> >>>> 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 <[email protected]> wrote: >>>> >>>>> 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 >>>>> <https://codereview.chromium.org/1157663007/diff/160001/src/compiler/register-allocator.h#newcode969src/compiler/register-allocator.h:969>: >>>>> if (a_start < b_start) return >>>>> a_end > b_start; >>>>> On 2015/06/12 04:09:12, jarin wrote: >>>>> > Out of curiosity, cannot you just leave out the "if (a_start == >>>>> b_start) return >>>>> > true" line and replace "a_start < b_start" with "a_start <= b_start"? >>>>> >>>>> > This special casing for equality seems a bit funny. >>>>> >>>>> > Perhaps you can even expand the recursive call, so the body would be: >>>>> >>>>> > if (a_start <= b_start) return b_start < a_end; >>>>> > return b_start <= a_start && a_start < b_end; >>>>> >>>>> Hmmm, this looks still too complicated, normally just a single line is >>>>> needed: >>>>> >>>>> return a_start <= b_end && b_start <= a_end; >>>>> >>>>> I'm not sure about the "open-ness" of our intervals, but I'm quite sure >>>>> that this condition can be tweaked to any convention. >>>>> >>>>> https://codereview.chromium.org/1157663007/ >>>>> >>>> >> > -- -- 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.
