Track whether local variables are initialized in the compiler.

[markshannon]

This is a simple dataflow analysis. For each load or store of a local variable we can track if the variable is initialized.
We can then use that information to specialize LOAD_FAST and STORE_FAST accordingly.

Consider x = y. The compiler can (in most cases) determine whether x and y are initialized.
Suppose we have two new instructions. LOAD_EVEN_FASTER and STORE_EVEN_FASTER which do not check for NULLness (feel free to mentally substitute more sensible names).
LOAD_EVEN_FASTER assumes that the variable is not NULL, so can avoid the NULL check.
STORE_EVEN_FASTER assumes that the variable is NULL, so avoids the read and the NULL check.

E.g.

def add(a, b, c):
      # a, b, c are all initialized. x and t are not.
      if c:
          t = b # t becomes initialized in this BB.
      # t maybe initialized.
      x = a + t # x becomes initialized and t must be initialized hereafter.
      return x - t

would be compiled as:

    LOAD_EVEN_FASTER c
    POP_JUMP_IF_FALSE label
    LOAD_EVEN_FASTER b
    STORE_EVEN_FASTER t
label:
    LOAD_EVEN_FASTER a
    LOAD_FAST t # t may not be initialized
    BINARY_OP  '+'
    STORE_EVEN_FASTER x
    LOAD_EVEN_FASTER x
    LOAD_EVEN_FASTER t # t must be initialized to reach here
    BINARY_OP  '-'
    RETURN_VALUE

We might also want CLEAR_THEN_STORE_FAST for when we are storing to a local that we know to be non NULL.

One problem is that a debugger can potentially set or delete variables.

1. Debugger wants to delete a non-NULL variable: Raise an exception. Debuggers can maybe issue a warning and set the variable to None
2. Debugger wants to set a NULL variable: Issue a warning. This might leak a reference to the value, as a subsequent STORE_EVEN_FASTER would not decrement its reference. I can think of no reliable way to avoid a memory leak here, but I think that a very rare refleak in the debugger is probably worth it.

[brandtbucher]

What if LOAD_EVEN_FASTER and STORE_EVEN_FASTER behave the same as LOAD_FAST and STORE_FAST, but get specialized to ACTUALLY_LOAD_EVEN_FASTER and ACTUALLY_STORE_EVEN_FASTER, which behave as you describe? That way we don't need to worry about tracing.

(We might have to do something like not using quickened code if a frame has ever been traced, but that doesn't seem too bad.)

I can think of no reliable way to avoid a memory leak here, but I think that a very rare refleak in the debugger is probably worth it.

Eh, we could stick these in a list on the frame somewhere and have it cleared when the frame exits, if we decided to go this route. It seems a bit heavy, but I personally view memory leaks as serious bugs (second only to interpreter crashes and incorrect behavior).

[markshannon]

Eh, we could stick these in a list on the frame somewhere and have it cleared when the frame exits, if we decided to go this route. It seems a bit heavy, but I personally view memory leaks as serious bugs (second only to interpreter crashes and incorrect behavior).

That won't work as they is no way to tell whether subsequent code will overwrite the variable or not. So the future reference count behavior is unpredictable.

[brandtbucher]

Hm, I thought with the dataflow analysis maybe we could (since the subsequent "real" store wouldn't actually decrement the reference count). But now I'm imagining cases where the "rogue" store happens in a conditional or something, and yeah, it doesn't seem possible.

[markshannon]

Specializing won't help either as a callee could turn on tracing.

[brandtbucher]

But as soon as they do that, then we deopt back to the unquickened code, which behaves as normal, right? That's why I added the comment:

(We might have to do something like not using quickened code if a frame has ever been traced, but that doesn't seem too bad.)

[TeamSpen210]

To solve the debugging issues, if tracing/debuggers are enabled (or when a local is set) we could go through and swap all these opcodes to regular LOAD/STORE_FAST, disabling this optimisation.

[brandtbucher]

Yep, that's basically what I suggested here.