Be able to bail out to deoptimized code

[DemiMarie]

Consider this function:

def simple_func(a, b, c):
    if a > b:
        return b if b > c else c
    else:
        return 0

To get good performance, we want to generate code that operates on machine integers, not Python objects. That means that we must:

• Profile and record that (as is likely here) a, b, and c are all integers normally.
• Generate optimized machine code that
  • tests that a, b, and c are machine integers
  • if not, bail out to the interpreter and deoptimize the generated code
  • otherwise, use the optimized machine code.

[brettcannon]

Demi Marie Obenour (@DemiMarie) the title is very generic, so I'm not quite sure what you're suggesting. What do you want Pyjion to do that it doesn't do already?

[DinoV]

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.