Uh oh!
There was an error while loading.Please reload this page.
- Notifications
You must be signed in to change notification settings - Fork33.7k
gh-93356: Lay out exception handling code at end of code unit#92769
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Uh oh!
There was an error while loading.Please reload this page.
Conversation
markshannon left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
Would it better to add awarm parameter tomark_reachable?mark_warm,mark_cold andmark_reachable are all doing the same thing, except for which edges they follow.
Uh oh!
There was an error while loading.Please reload this page.
markshannon commentedMay 13, 2022
Why does fall through from a cold block to a warm block need to be treated specially? Unless I'm mistaken: |
iritkatriel commentedMay 13, 2022
We can't change b->next of a block with a fallthrough. |
markshannon commentedMay 13, 2022
You could convert it to a jump and eliminate the fallthrough edge. |
iritkatriel commentedMay 13, 2022
That's the idea. But there could already be a conditional jump there, so if we don't want to have to worry about multiple jumps in the same block for the remaining parts of the assembler, it needs to be a new block. |
…gs calculated only once. don't pass compiler/assembler around as much
iritkatriel commentedMay 13, 2022
My first version did mark_cold/warm at the same time as mark_reachable. But I had a situation where the graph changed between that time and the time when I can do the push_cold_to_end. So now mark cold/warm happens just before push_cold_to_end. I could possibly share the code though. |
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Uh oh!
There was an error while loading.Please reload this page.
Python/compile.c Outdated
| while(b&&b->b_next) { | ||
| basicblock*next=b->b_next; | ||
| if (next->b_cold) { | ||
| if (next->b_next) { | ||
| b->b_next=next->b_next; | ||
| next->b_next=NULL; | ||
| tail->b_next=next; | ||
| tail=next; | ||
| } | ||
| }else { | ||
| b=next; | ||
| } | ||
| if(next==origtail) { | ||
| break; | ||
| } | ||
| } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
This took me a while to understand, but maybe that's just the nature of linked list code.
My biggest confusion was that meaningful fallthroughb_next linkages are broken and then re-established. There could maybe be an inner loop to scan for streaks of cold blocks, so that they can all be moved to the end with an assignment each tob.b_next, tail.b_next, last_of_streak.b_next, but I'm not sure if that makes the edge cases easier or harder.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I think the new version is easier to follow. Let me know.
sweeneyde commentedJun 1, 2022
LGTM. I think the linked list change is clearer now, thanks. |
bedevere-bot commentedJun 1, 2022
🤖 New build scheduled with the buildbot fleet by@iritkatriel for commit6a454c8 🤖 If you want to schedule another build, you need to add the ":hammer: test-with-buildbots" label again. |
iritkatriel commentedJun 1, 2022
Buildbots are happy. 🍾 |
Uh oh!
There was an error while loading.Please reload this page.
Closes#93356.