-
-
Notifications
You must be signed in to change notification settings - Fork 31.8k
gh-101799: implement PREP_RERAISE_STAR as an intrinsic function #101800
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 our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
iritkatriel
commented
Feb 10, 2023
•
edited by bedevere-bot
Loading
edited by bedevere-bot
- Issue: PREP_RERAISE_STAR can be replaced by an intrinsic function #101799
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.
Quick comment: Why not add a CALL_INTRINSIC_2 opcode (assuming we expect more of these)? The variable stack effect based on comparison with an arbitrary constant feels a little fragile. Maybe it would feel less arbitrary if the constant was actually 128 (i.e., bit 7, 0x80).
I considered this, the down side is we have two opcodes for non-perf-critical stuff. I don't have a strong opinion either way. @markshannon ? |
Is FORMAT_VALUE performance critical? It could be replaced by a couple of intrinsic functions. |
Possibly. Most of it could become a helper function. This would lose the fast path for |
Usually we want to do dispatching in the dispatch loop, not within instructions. On balance, I still think we want two instructions. The extra test and branch is messy; two instructions would make for clearer code and we aren't that short of opcodes. |
Regarding
|
b432958
to
8899015
Compare
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.
Looks good.