Skip to content

Feat: Implemented type propagation #24

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

JuliaPoo
Copy link
Collaborator

@JuliaPoo JuliaPoo commented Mar 2, 2023

This pull requests contains:

  1. Additional features to the DSL and corresponding changes in bytecode.c for the type propagation
    • DSL has type annotations referencing the local and const arrays
    • DSL allows annotating local array effect

Example:

// The stack effect `value` is type annotated by an index into the const array: `consts[oparg]`
inst(LOAD_CONST, (-- value : consts[oparg])) {
    value = GETITEM(consts, oparg);
    Py_INCREF(value);
}

// The local array effect is annotated after the stack effect as `locals[oparg] = *value`, 
// `*value` indicating that the variable is a stack variable (as opposed to a literal like `PyLong_Type`)
inst(STORE_FAST, (value --), locals[oparg] = *value) {
    SETLOCAL(oparg, value);
}
  1. Generated the type propagator:
    • The type propagator is located at tier2_typepropagator.c.h which is inlined into tier2.c. This file deals with type propagation across all tier2 bytecode except for BB_TEST_IF_FALSE_OR_POP and BB_TEST_IF_TRUE_OR_POP because it's stack effect is dependent on branch taken
    • Type propagation happens on the DISPATCH() call in _PyTier2_Code_DetectAndEmitBB, which accounts for all tier2 bytecode except branch instructions
    • Type propagation for branch instructions happens within emit_logical_branch, which deals with type propagation except for the two above mentioned instructions
    • Type propagation for the last two instructions are dealt within BB_BRANCH, where both BB_TEST_IF_FALSE_OR_POP and BB_TEST_IF_TRUE_OR_POP sets a flag gen_bb_requires_pop during runtime which gets used in BB_BRANCH to perform the corresponding pop on the type context for the next BB.

Other misc (but important) changes:

  1. type_context is now its own struct
  2. _PyTier2_Code_DetectAndEmitBB no longer makes a copy of the type_context and instead modifies the type context passed into it. Callers of this function should make a copy if needed.

Future work:

  1. Add more annotations/type specialised instructions to the DSL, there's a chance the cases generator breaks bcuz of a bug from the code introduced here
  2. Memory used by a type_context from a BB who's target branches have all been generated can be reused without additional allocations, since said BB doesn't require a type_context anymore.

Fidget-Spinner and others added 15 commits February 24, 2023 21:33
…_bbs' into types_metainterpreter

# Conflicts:
#	Include/internal/pycore_opcode_macro_to_micro.h
Might require a refactor of the tier2 bytecode emitting code to progress.
When emitting from a codeobject (with tier1 bytecode):

1. deop inst back to tier0
2. emit tier2 inst based on current type context
3. type propagate through emitted inst

This allows the type propagator to work with tier2 bytecode (which contains more information)
and can probably be generated from the DSL
In preparation for type propagating within the tier2 branch handling code
@Fidget-Spinner Fidget-Spinner merged commit eeaa02f into Fidget-Spinner:tier2_interpreter_no_separate_eval_no_tracer_contiguous_bbs Mar 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants