[turboshaft] Use rolling window for random scheduling phase [v8/v8 : main]
Matthias Liedtke (Gerrit)
Matthias Liedtke added 2 comments![]( "Open in Gerrit")
if (op_states_[index] != OpState::kScheduled && !op.Is<PhiOp>() &&
!op.Is<ParameterOp>() && !op.Is<CatchBlockBeginOp>() &&
!op.IsBlockTerminator()) {Alternatively, we could also unconditionally count until 30 instead of letting the window grow larger if we have any more unschedulable operations? (I think they can still appear as there have been some discussions about it in the past and even "all loop phis are directly at the beginning of the loop block" didn't seem to hold true IIRC.)
Related details
- Darius Mercadier
- Nico Hartmann
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Nico Hartmann (Gerrit)
Nico Hartmann added 1 comment![]( "Open in Gerrit")
This solution looks very complex to me. What I had in mind initially is to add a few bailouts in `ComputeReadyOperations`. Those can be when
a.) The set already has X number of ready operations.
b.) The used bits (or a specific subset of those) of `produced_effects` are X% populated and it gets increasingly unlikely that we can schedule anything else anyway.
c.) We have looked at a hard limit of X operations following the first unscheduled operation (this would have to be cached, which is probably a good idea anyway).
Related details
- Darius Mercadier
- Matthias Liedtke
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Matthias Liedtke (Gerrit)
Matthias Liedtke voted and added 1 comment![]( "Open in Gerrit")
Votes added by Matthias Liedtke
| Commit-Queue | +1 |
This solution looks very complex to me. What I had in mind initially is to add a few bailouts in `ComputeReadyOperations`. Those can be when
a.) The set already has X number of ready operations.
b.) The used bits (or a specific subset of those) of `produced_effects` are X% populated and it gets increasingly unlikely that we can schedule anything else anyway.
c.) We have looked at a hard limit of X operations following the first unscheduled operation (this would have to be cached, which is probably a good idea anyway).
Simplicity is in the eye of the beholder. AI didn't want to integrate it in a nice way into the `ComputeReadyOperations`. I did it manually now but if we want to integrate it into the existing iteration in `ComputeReadyOperations`, then obviously this iteration becomes more complicated (like the switching of the iterator mid-iteration.)
Related details
- Darius Mercadier
- Nico Hartmann
Code-Owners
Code-Review
No-Unresolved-Comments
Review-Enforcement
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |