Rewrite pending specifics to use the work stack #6415
Conversation
jonmeow
force-pushed
the
import-pending
branch
from
8a7cced to
857215b
Compare
chandlerc
left a comment
chandlerc
left a comment
There was a problem hiding this comment.
Nice! The rationale makes lots of sense to me, suggested maybe even capturing some of that in code comments so its more visible.
|
|
||
| auto ImportRefResolver::PushSpecific(SemIR::SpecificId import_id, | ||
| SemIR::SpecificId local_id) -> void { | ||
| // Insert before the current instruction. |
There was a problem hiding this comment.
Maybe add to this comment some of the nuance from the commit message around inserting into the middle of the work stack and why it should be fine?
Mostly thinking it could be helpful if this function shows up in a profile at some point because something weird changed, or if someone worries about the insert here.
There was a problem hiding this comment.
On the function declaration, I have:
// Pushes a specific onto the work stack. This will only process when the
// current instruction is done, and does not count towards `HasNewWork`. We
// add specifics this way because some instructions (e.g. `FacetTypeInfo`) can
// add multiple specifics.
Are there other details you're looking for? Typically I wouldn't expect discarded alternatives to be part of the implementation description -- if somebody wanted to try the other approach and it performed better, wouldn't that be fine?
There was a problem hiding this comment.
I was thinking some of the content in the commit message... maybe something along the lines of:
Note that this will do extra work moving existing entries on the work stack, but that is expected to be OK because the common cases are 0 or 1 specifics being added. If this ends up showing up in profiles, potentially due to vector growth, it may be worth revisiting.
Still, optional, change looks good either way.
|
|
||
| auto ImportRefResolver::PushSpecific(SemIR::SpecificId import_id, | ||
| SemIR::SpecificId local_id) -> void { | ||
| // Insert before the current instruction. |
There was a problem hiding this comment.
I was thinking some of the content in the commit message... maybe something along the lines of:
Note that this will do extra work moving existing entries on the work stack, but that is expected to be OK because the common cases are 0 or 1 specifics being added. If this ends up showing up in profiles, potentially due to vector growth, it may be worth revisiting.
Still, optional, change looks good either way.
2 participants
I was trying to figure out the right way to get specifics to be added to the work.
Technically, we could keep the pending_specific list; this is taking a different approach of inserting inside the work stack, which will do extra work moving entries, although typically that should be expected to be small. One challenge of
pending_specificsis that if we would need to shift them to work after bothDone(for immediate processing) andRetry(for processing after the current instruction is later revisited and done). That feels kind of awkward as additional tracking to do. Also, the common case is probably that there's either 0 or 1 specifics being added, so an additional vector may be significant overhead. That's why I leaned more in this direction of just inserting them in the vector of work.