You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Oct 12, 2022. It is now read-only.
FYI we currently trace the arguments for the function call (a,b,c) and generate optimized versions of the function based upon the argument types - potentially generating several different optimized versions for polymorphic calls.
For integer types we'll always do tagged pointers for integers because we don't yet do any range analysis which would allow us to treat them as 100% native ints.
We don't generate machine code for the tests when entering a method - instead that's a common entrypoint. In the future we'll presumably have inline guards which protect specific code paths. That's where the bail to the interpreter and de-optimize the code will really come into play I think.
brettcannon
changed the title
Deoptimization
Be able to bail out to deoptimized code
Jul 5, 2017
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Consider this function:
To get good performance, we want to generate code that operates on machine integers, not Python objects. That means that we must:
The text was updated successfully, but these errors were encountered: