Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
1901713003:
[generators] Perform state dispatch in loop header. (Closed)
Description[generators] Perform state dispatch in loop header.
This is necessary to eventually build a turbofan graph.
BUG=v8:4907
LOG=n
Committed: https://crrev.com/42c0e2ec7c831d67a25be0e458a3513ae014fa4a
Cr-Commit-Position: refs/heads/master@{#35820}
Patch Set 1 #
Total comments: 10
Patch Set 2 : #Patch Set 3 : #Patch Set 4 : Make Windows happy #
Total comments: 5
Patch Set 5 : Again #Patch Set 6 : #Patch Set 7 : #
Total comments: 6
Patch Set 8 : Address comments #
Messages
Total messages: 39 (15 generated)
rmcilroy@chromium.org changed reviewers: + rmcilroy@chromium.org
Some high level comments. https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ar... File src/interpreter/bytecode-array-builder.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ar... src/interpreter/bytecode-array-builder.cc:881: BytecodeArrayBuilder& BytecodeArrayBuilder::IndexedJump( As mentioned in a comment below, I think this should also live in the BytecodeGenerator (along with the resume points and yields seen). Doing this here breaks the abstraction between BytecodeGenerator (which is meant to be where the logic of turning JS into bytecode lives) and BytecodeArrayBuilder (which is meant to simply abstract over bytecode creation and output). https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ge... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ge... src/interpreter/bytecode-generator.cc:653: Register state = Register::new_target(); // HACK Could you allocate an additional local for this purpose in the AST visitor (similar to the arguments, this_function or new_target variables)? If you did this then you could store the resume state in that local throughout the execution. This would be the cleanest solution I think. Another possibility would be to allocate a temporary register in BytecodeGenerator::MakeBytecode, and keep the allocator scoped throughout the whole function generation so that it can be reuse throughout the function, but I'm not super keen on this since it seems a bit hacky. https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... File src/interpreter/control-flow-builders.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... src/interpreter/control-flow-builders.cc:125: .Bind(¬_resuming); I really think this logic should live in the bytecode-generator. How about rather than passing the yield_count to the builder, we just pass a list of additional labels to bind at the loop header (i.e., the yield resume points between yields_seen and yields_seen + yield_count), and then we add a function in BytecodeGenerator for VisitIterationHeader(IterationStatement* stmt, LoopBuilder* loop_builder) to do the logic about jumping to the inner yield points and updating the labels in the resume_points list to be new BytecodeLabels pointing to the new inner resume points. WDYT? https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... src/interpreter/control-flow-builders.cc:139: .StoreAccumulatorInRegister(state); Could we instead set the resume value to -1 at the final resume point (i.e., in VisitYield after the resume)?
https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ar... File src/interpreter/bytecode-array-builder.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ar... src/interpreter/bytecode-array-builder.cc:881: BytecodeArrayBuilder& BytecodeArrayBuilder::IndexedJump( On 2016/04/19 09:30:03, rmcilroy wrote: > As mentioned in a comment below, I think this should also live in the > BytecodeGenerator (along with the resume points and yields seen). Doing this > here breaks the abstraction between BytecodeGenerator (which is meant to be > where the logic of turning JS into bytecode lives) and BytecodeArrayBuilder > (which is meant to simply abstract over bytecode creation and output). Ack. I thought my IndexedJump would fit well next to the JumpIfFoo functions but I didn't realize that those all have their own bytecode. https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ge... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/bytecode-ge... src/interpreter/bytecode-generator.cc:653: Register state = Register::new_target(); // HACK On 2016/04/19 09:30:03, rmcilroy wrote: > Could you allocate an additional local for this purpose in the AST visitor > (similar to the arguments, this_function or new_target variables)? If you did > this then you could store the resume state in that local throughout the > execution. This would be the cleanest solution I think. > > Another possibility would be to allocate a temporary register in > BytecodeGenerator::MakeBytecode, and keep the allocator scoped throughout the > whole function generation so that it can be reuse throughout the function, but > I'm not super keen on this since it seems a bit hacky. I think I prefer having a dedicated register rather than adding more magic to the AST (that would only be used by the interpreter). I will find out what the other folks think. https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... File src/interpreter/control-flow-builders.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... src/interpreter/control-flow-builders.cc:125: .Bind(¬_resuming); On 2016/04/19 09:30:03, rmcilroy wrote: > I really think this logic should live in the bytecode-generator. How about > rather than passing the yield_count to the builder, we just pass a list of > additional labels to bind at the loop header (i.e., the yield resume points > between yields_seen and yields_seen + yield_count), and then we add a function > in BytecodeGenerator for VisitIterationHeader(IterationStatement* stmt, > LoopBuilder* loop_builder) to do the logic about jumping to the inner yield > points and updating the labels in the resume_points list to be new > BytecodeLabels pointing to the new inner resume points. WDYT? See my comments below. https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... src/interpreter/control-flow-builders.cc:139: .StoreAccumulatorInRegister(state); On 2016/04/19 09:30:03, rmcilroy wrote: > Could we instead set the resume value to -1 at the final resume point (i.e., in > VisitYield after the resume)? There is no "final" yield. Eg.: while (...) { ... if (...) { yield } else { yield } } Semantically, JumpToHeader is the right place where this internal state change should happen. I was actually quite happy with how my changes were encapsulated in LoopHeader and JumpToHeader and it makes a lot of sense to me that those are the places to modify. What don't you like about it?
https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... File src/interpreter/control-flow-builders.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... src/interpreter/control-flow-builders.cc:139: .StoreAccumulatorInRegister(state); On 2016/04/19 11:02:15, neis wrote: > On 2016/04/19 09:30:03, rmcilroy wrote: > > Could we instead set the resume value to -1 at the final resume point (i.e., > in > > VisitYield after the resume)? > > There is no "final" yield. Eg.: > while (...) { > ... > if (...) { yield } else { yield } > } Both of these are different yield points though, right - and both will have their own VisitYield(). The resume state should only be set to something other than -1 if we are eventually going to resume in one of these VisitYield points. If we set the state register to -1 immediately after the builder()->Bind(&(generator_resume_points_[id])) in each of the Yield points then we will never end up jumping back to a header with the something other than "not resume". > Semantically, JumpToHeader is the right place where this internal state change > should happen. I don't agree, I think it should happen once we have fully resumed, after that it should never be set to something other than -1. > I was actually quite happy with how my changes were encapsulated in LoopHeader > and JumpToHeader and it makes a lot of sense to me that those are the places to > modify. What don't you like about it? The bytecode array builder shouldn't know about generators or yield points. Doing it in a VisitIterationHeader (similar to the VisitIterationBody function) in Bytecode generator also keeps changes encapsulated, and keeps all the logic for generators in BytecodeGenerator.
On 2016/04/19 11:14:26, rmcilroy wrote: > https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... > File src/interpreter/control-flow-builders.cc (right): > > https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... > src/interpreter/control-flow-builders.cc:139: > .StoreAccumulatorInRegister(state); > On 2016/04/19 11:02:15, neis wrote: > > On 2016/04/19 09:30:03, rmcilroy wrote: > > > Could we instead set the resume value to -1 at the final resume point (i.e., > > in > > > VisitYield after the resume)? > > > > There is no "final" yield. Eg.: > > while (...) { > > ... > > if (...) { yield } else { yield } > > } > > Both of these are different yield points though, right - and both will have > their own VisitYield(). The resume state should only be set to something other > than -1 if we are eventually going to resume in one of these VisitYield points. > If we set the state register to -1 immediately after the > builder()->Bind(&(generator_resume_points_[id])) in each of the Yield points > then we will never end up jumping back to a header with the something other than > "not resume". Ok, now you are suggesting to set the state to -1 after every yield. That's possible, but why do the assignment at each yield in the entire generator function (even outside loops I suppose?) when all we need is do it once at the end of each loop? The state register and its magic value are an implementation detail of the loop dispatch, currently VisitYield doesn't even know about their existence. That's why I think that JumpToHeader is the right place. > > I was actually quite happy with how my changes were encapsulated in LoopHeader > > and JumpToHeader and it makes a lot of sense to me that those are the places > to > > modify. What don't you like about it? > > The bytecode array builder shouldn't know about generators or yield points. > Doing it in a VisitIterationHeader (similar to the > VisitIterationBody function) in Bytecode generator also keeps changes > encapsulated, and keeps all the logic for generators in BytecodeGenerator. I agree that the bytecode array builder shouldn't need to know about it, I'm not arguing that it should. I'm arguing that the the loop machinery should know about it, because its job is to ensure the "ordering requirements" mentioned in the comment at the top of LoopHeader().
On 2016/04/19 11:46:00, neis wrote: > On 2016/04/19 11:14:26, rmcilroy wrote: > > > https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... > > File src/interpreter/control-flow-builders.cc (right): > > > > > https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... > > src/interpreter/control-flow-builders.cc:139: > > .StoreAccumulatorInRegister(state); > > On 2016/04/19 11:02:15, neis wrote: > > > On 2016/04/19 09:30:03, rmcilroy wrote: > > > > Could we instead set the resume value to -1 at the final resume point > (i.e., > > > in > > > > VisitYield after the resume)? > > > > > > There is no "final" yield. Eg.: > > > while (...) { > > > ... > > > if (...) { yield } else { yield } > > > } > > > > Both of these are different yield points though, right - and both will have > > their own VisitYield(). The resume state should only be set to something other > > than -1 if we are eventually going to resume in one of these VisitYield > points. > > If we set the state register to -1 immediately after the > > builder()->Bind(&(generator_resume_points_[id])) in each of the Yield points > > then we will never end up jumping back to a header with the something other > than > > "not resume". > > Ok, now you are suggesting to set the state to -1 after every yield. This is what I was originally suggesting, sorry if I wasn't clear. > That's possible, but why do the assignment at each yield in the entire generator > function (even outside loops I suppose?) when all we need is do it once at the > end of each loop? Doing it once at the end of loops is potentially even more work than doing it at each resume point - e.g, what if there is a conditional yield within a loop, you would need to do this work on every loop iteration with the current approach, whereas you should only need to do it when the loop actually yields/resumes. Also with nested loops, you end up doing it in the outer loops as well as the inner-most loop, even if the yield is only in the inner-most loop. > The state register and its magic value are an implementation > detail of the loop dispatch, currently VisitYield doesn't even know about their > existence. That's why I think that JumpToHeader is the right place. The state register is known about by BytecodeGenerator::VisitGeneratorPrologue, which is what sets it initially. This means that the knowledge is spread over both bytecode-generator and control-flow-builders (another reason I'd like to move this knowledge into the bytecode generator). Also, I'm not sure this is always correct, e.g., what happens for: function foo() { yield; while (...) { yield; } } I think that when the first non-loop yield resumes, VisitGeneratorPrologue will set this state register to a value other than "-1", and the code in VisitYield will not set it back to "-1". As execution continues we enter the while loop's loop header without ever having executed a JumpToHeader and so we will have a non "-1" value, which will cause the loop header to try to resume rather than running the non-resuming at this point. > > > I was actually quite happy with how my changes were encapsulated in > LoopHeader > > > and JumpToHeader and it makes a lot of sense to me that those are the places > > to > > > modify. What don't you like about it? > > > > The bytecode array builder shouldn't know about generators or yield points. > > Doing it in a VisitIterationHeader (similar to the > > VisitIterationBody function) in Bytecode generator also keeps changes > > encapsulated, and keeps all the logic for generators in BytecodeGenerator. > > I agree that the bytecode array builder shouldn't need to know about it, I'm not > arguing that it should. I'm arguing that the the loop machinery should know > about it, because its job is to ensure the "ordering requirements" mentioned in > the comment at the top of LoopHeader(). It's part and parcel - since the control flow builder doesn't have access to the BytecodeGenerator, we need to make the bytecode array builder have knowledge of it if the logic goes here. Note - I agree that the job of the control flow builder is to keep track of the ordering requirements, that's why I suggested passing it the additional set of labels to bind in the loop header for the loop header resume points, however it's job is not to ensure that the generator resumes at the right location, that should be done in the bytecode generator.
> Doing it once at the end of loops is potentially even more work than doing it
at
> each resume point - e.g, what if there is a conditional yield within a loop,
you
> would need to do this work on every loop iteration with the current approach,
> whereas you should only need to do it when the loop actually yields/resumes.
> Also with nested loops, you end up doing it in the outer loops as well as the
> inner-most loop, even if the yield is only in the inner-most loop.
Yeah that's right, both approaches have their cons and pros.
> > The state register and its magic value are an implementation
> > detail of the loop dispatch, currently VisitYield doesn't even know about
> their
> > existence. That's why I think that JumpToHeader is the right place.
>
> The state register is known about by
BytecodeGenerator::VisitGeneratorPrologue,
> which is what sets it initially. This means that the knowledge is spread over
> both bytecode-generator and control-flow-builders (another reason I'd like to
> move this knowledge into the bytecode generator).
That's merely an optimization, though: I wanted to avoid reloading the state
from the generator object before entering a loop dispatch.
> Also, I'm not sure this is always correct, e.g., what happens for:
>
> function foo() {
> yield;
> while (...) {
> yield;
> }
> }
>
> I think that when the first non-loop yield resumes, VisitGeneratorPrologue
will
> set this state register to a value other than "-1", and the code in VisitYield
> will not set it back to "-1". As execution continues we enter the while loop's
> loop header without ever having executed a JumpToHeader and so we will have a
> non "-1" value, which will cause the loop header to try to resume rather than
> running the non-resuming at this point.
The loop header code will see that the state is less than the number of yields
seen at this point. It doesn't matter if that value is the id of an actual
earlier resume point or the sentinel -1.
> > > > I was actually quite happy with how my changes were encapsulated in
> > LoopHeader
> > > > and JumpToHeader and it makes a lot of sense to me that those are the
> places
> > > to
> > > > modify. What don't you like about it?
> > >
> > > The bytecode array builder shouldn't know about generators or yield
points.
> > > Doing it in a VisitIterationHeader (similar to the
> > > VisitIterationBody function) in Bytecode generator also keeps changes
> > > encapsulated, and keeps all the logic for generators in BytecodeGenerator.
> >
> > I agree that the bytecode array builder shouldn't need to know about it, I'm
> not
> > arguing that it should. I'm arguing that the the loop machinery should know
> > about it, because its job is to ensure the "ordering requirements" mentioned
> in
> > the comment at the top of LoopHeader().
>
> It's part and parcel - since the control flow builder doesn't have access to
the
> BytecodeGenerator, we need to make the bytecode array builder have knowledge
of
> it if the logic goes here. Note - I agree that the job of the control flow
> builder is to keep track of the ordering requirements, that's why I suggested
> passing it the additional set of labels to bind in the loop header for the
loop
> header resume points, however it's job is not to ensure that the generator
> resumes at the right location, that should be done in the bytecode generator.
I see. Is there a strong reason for the control flow builder to be independent
of the bytecode generator? Anyway, if there's no good way to implement my
preference without polluting the array builder or major restructuring, then I'm
fine with following your suggestion.
jarin@chromium.org changed reviewers: + jarin@chromium.org
https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... File src/interpreter/control-flow-builders.cc (right): https://codereview.chromium.org/1901713003/diff/1/src/interpreter/control-flo... src/interpreter/control-flow-builders.cc:139: .StoreAccumulatorInRegister(state); On 2016/04/19 11:14:26, rmcilroy wrote: > On 2016/04/19 11:02:15, neis wrote: > > On 2016/04/19 09:30:03, rmcilroy wrote: > > > Could we instead set the resume value to -1 at the final resume point (i.e., > > in > > > VisitYield after the resume)? > > > > There is no "final" yield. Eg.: > > while (...) { > > ... > > if (...) { yield } else { yield } > > } > > Both of these are different yield points though, right - and both will have > their own VisitYield(). The resume state should only be set to something other > than -1 if we are eventually going to resume in one of these VisitYield points. > If we set the state register to -1 immediately after the > builder()->Bind(&(generator_resume_points_[id])) in each of the Yield points > then we will never end up jumping back to a header with the something other than > "not resume". Indeed, I thought we set the state to -1 after the bind in VisitYield, so we should always see the state -1 when jumping back to loop header. (We should only jump forward when resuming.)
PTAL. Moved stuff out of arraybuilder etc.
PTAL. Moved stuff out of arraybuilder etc.
The CQ bit was checked by neis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1901713003/40001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1901713003/40001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_nosnap_shared_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
The CQ bit was checked by neis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1901713003/60001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1901713003/60001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_rel_ng/builds/6291)
The CQ bit was checked by neis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1901713003/80001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1901713003/80001
https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/bytecod... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/bytecod... src/interpreter/bytecode-generator.cc:656: // for these resume points, to be used inside the loop. I am wondering whether you should not say something about non-generator functions here (I assume for normal functions stmt->yield_count() is 0?). https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/control... File src/interpreter/control-flow-builders.cc (right): https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/control... src/interpreter/control-flow-builders.cc:102: } Any reason why you cannot bind in BytecodeGenerator::VisitIterationHeader?
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: v8_win_nosnap_shared_rel_ng on tryserver.v8 (JOB_FAILED, http://build.chromium.org/p/tryserver.v8/builders/v8_win_nosnap_shared_rel_ng...)
The CQ bit was checked by neis@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1901713003/120001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1901713003/120001
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/bytecod... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/bytecod... src/interpreter/bytecode-generator.cc:656: // for these resume points, to be used inside the loop. On 2016/04/26 12:59:51, Jarin wrote: > I am wondering whether you should not say something about non-generator > functions here (I assume for normal functions stmt->yield_count() is 0?). Acknowledged. Regarding your question: yes https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/control... File src/interpreter/control-flow-builders.cc (right): https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/control... src/interpreter/control-flow-builders.cc:102: } On 2016/04/26 12:59:51, Jarin wrote: > Any reason why you cannot bind in BytecodeGenerator::VisitIterationHeader? I can, but see the previous discussion. I leave it up to Ross.
LGTM, thanks for making these changes. https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... src/interpreter/bytecode-generator.cc:639: void BytecodeGenerator::BuildIndexedJump(Register index, int min, size_t size, nit /s/min/start_index/ https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... src/interpreter/bytecode-generator.cc:659: id < generator_yields_seen_ + static_cast<int>(stmt->yield_count()); How about making generator_yields_seen_ and id size_t to avoid the casting here? https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... src/interpreter/bytecode-generator.cc:684: Register generator_object = Register::new_target(); nit - could you add a comment here that generator functions use the new_target register for passing the generator object since they can never be called as a constructor.
Description was changed from ========== [generators] Perform state dispatch in loop header. BUG= ========== to ========== [generators] Perform state dispatch in loop header. This is necessary to eventually build a turbofan graph. BUG=v8:4907 LOG=n ==========
https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/bytecod... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/60001/src/interpreter/bytecod... src/interpreter/bytecode-generator.cc:656: // for these resume points, to be used inside the loop. On 2016/04/26 12:59:51, Jarin wrote: > I am wondering whether you should not say something about non-generator > functions here (I assume for normal functions stmt->yield_count() is 0?). Done. https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... File src/interpreter/bytecode-generator.cc (right): https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... src/interpreter/bytecode-generator.cc:639: void BytecodeGenerator::BuildIndexedJump(Register index, int min, size_t size, On 2016/04/27 11:02:26, rmcilroy wrote: > nit /s/min/start_index/ Done. https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... src/interpreter/bytecode-generator.cc:659: id < generator_yields_seen_ + static_cast<int>(stmt->yield_count()); On 2016/04/27 11:02:26, rmcilroy wrote: > How about making generator_yields_seen_ and id size_t to avoid the casting here? Done. Had to cast elsewhere though. https://codereview.chromium.org/1901713003/diff/120001/src/interpreter/byteco... src/interpreter/bytecode-generator.cc:684: Register generator_object = Register::new_target(); On 2016/04/27 11:02:26, rmcilroy wrote: > nit - could you add a comment here that generator functions use the new_target > register for passing the generator object since they can never be called as a > constructor. Done.
The CQ bit was checked by neis@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from rmcilroy@chromium.org Link to the patchset: https://codereview.chromium.org/1901713003/#ps140001 (title: "Address comments")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/patch-status/1901713003/140001 View timeline at https://chromium-cq-status.appspot.com/patch-timeline/1901713003/140001
Message was sent while issue was closed.
Description was changed from ========== [generators] Perform state dispatch in loop header. This is necessary to eventually build a turbofan graph. BUG=v8:4907 LOG=n ========== to ========== [generators] Perform state dispatch in loop header. This is necessary to eventually build a turbofan graph. BUG=v8:4907 LOG=n ==========
Message was sent while issue was closed.
Committed patchset #8 (id:140001)
Message was sent while issue was closed.
Description was changed from ========== [generators] Perform state dispatch in loop header. This is necessary to eventually build a turbofan graph. BUG=v8:4907 LOG=n ========== to ========== [generators] Perform state dispatch in loop header. This is necessary to eventually build a turbofan graph. BUG=v8:4907 LOG=n Committed: https://crrev.com/42c0e2ec7c831d67a25be0e458a3513ae014fa4a Cr-Commit-Position: refs/heads/master@{#35820} ==========
Message was sent while issue was closed.
Patchset 8 (id:??) landed as https://crrev.com/42c0e2ec7c831d67a25be0e458a3513ae014fa4a Cr-Commit-Position: refs/heads/master@{#35820} |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
