2023-08-16 02:04:17 +08:00
|
|
|
#ifndef Py_INTERNAL_OPTIMIZER_H
|
|
|
|
|
#define Py_INTERNAL_OPTIMIZER_H
|
|
|
|
|
#ifdef __cplusplus
|
|
|
|
|
extern "C" {
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#ifndef Py_BUILD_CORE
|
|
|
|
|
# error "this header requires Py_BUILD_CORE define"
|
|
|
|
|
#endif
|
|
|
|
|
|
2025-03-19 15:23:32 +01:00
|
|
|
#include "pycore_typedefs.h" // _PyInterpreterFrame
|
2025-09-17 18:50:16 +01:00
|
|
|
#include "pycore_uop.h" // _PyUOpInstruction
|
2024-02-13 21:24:48 +08:00
|
|
|
#include "pycore_uop_ids.h"
|
2025-06-27 19:37:44 +08:00
|
|
|
#include "pycore_stackref.h" // _PyStackRef
|
2026-01-09 03:38:21 +08:00
|
|
|
#include "pycore_optimizer_types.h"
|
2024-02-27 10:51:26 +00:00
|
|
|
#include <stdbool.h>
|
2024-02-13 21:24:48 +08:00
|
|
|
|
2024-06-26 13:54:03 +02:00
|
|
|
|
2026-01-22 10:55:49 +00:00
|
|
|
typedef struct _PyJitUopBuffer {
|
|
|
|
|
_PyUOpInstruction *start;
|
|
|
|
|
_PyUOpInstruction *next;
|
|
|
|
|
_PyUOpInstruction *end;
|
|
|
|
|
} _PyJitUopBuffer;
|
|
|
|
|
|
2026-02-19 11:52:57 +00:00
|
|
|
typedef struct _JitOptRefBuffer {
|
|
|
|
|
JitOptRef *used;
|
|
|
|
|
JitOptRef *end;
|
|
|
|
|
} _JitOptRefBuffer;
|
2026-01-22 10:55:49 +00:00
|
|
|
|
|
|
|
|
typedef struct _JitOptContext {
|
|
|
|
|
char done;
|
|
|
|
|
char out_of_space;
|
|
|
|
|
bool contradiction;
|
|
|
|
|
// Has the builtins dict been watched?
|
|
|
|
|
bool builtins_watched;
|
|
|
|
|
// The current "executing" frame.
|
|
|
|
|
_Py_UOpsAbstractFrame *frame;
|
|
|
|
|
_Py_UOpsAbstractFrame frames[MAX_ABSTRACT_FRAME_DEPTH];
|
|
|
|
|
int curr_frame_depth;
|
|
|
|
|
|
|
|
|
|
// Arena for the symbolic types.
|
|
|
|
|
ty_arena t_arena;
|
|
|
|
|
|
2026-02-19 11:52:57 +00:00
|
|
|
/* To do -- We could make this more space efficient
|
|
|
|
|
* by using a single array and growing the stack and
|
|
|
|
|
* locals toward each other. */
|
|
|
|
|
_JitOptRefBuffer locals;
|
|
|
|
|
_JitOptRefBuffer stack;
|
|
|
|
|
JitOptRef locals_array[ABSTRACT_INTERP_LOCALS_SIZE];
|
|
|
|
|
JitOptRef stack_array[ABSTRACT_INTERP_STACK_SIZE];
|
2026-01-22 10:55:49 +00:00
|
|
|
_PyJitUopBuffer out_buffer;
|
2026-02-19 11:52:57 +00:00
|
|
|
_PyBloomFilter *dependencies;
|
2026-01-22 10:55:49 +00:00
|
|
|
} JitOptContext;
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
uop_buffer_init(_PyJitUopBuffer *trace, _PyUOpInstruction *start, uint32_t size)
|
|
|
|
|
{
|
|
|
|
|
trace->next = trace->start = start;
|
|
|
|
|
trace->end = start + size;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline _PyUOpInstruction *
|
|
|
|
|
uop_buffer_last(_PyJitUopBuffer *trace)
|
|
|
|
|
{
|
|
|
|
|
assert(trace->next > trace->start);
|
|
|
|
|
return trace->next-1;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
uop_buffer_length(_PyJitUopBuffer *trace)
|
|
|
|
|
{
|
|
|
|
|
return (int)(trace->next - trace->start);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
uop_buffer_remaining_space(_PyJitUopBuffer *trace)
|
|
|
|
|
{
|
|
|
|
|
return (int)(trace->end - trace->next);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
typedef struct _PyJitTracerInitialState {
|
|
|
|
|
int stack_depth;
|
|
|
|
|
int chain_depth;
|
|
|
|
|
struct _PyExitData *exit;
|
|
|
|
|
PyCodeObject *code; // Strong
|
|
|
|
|
PyFunctionObject *func; // Strong
|
|
|
|
|
struct _PyExecutorObject *executor; // Strong
|
|
|
|
|
_Py_CODEUNIT *start_instr;
|
|
|
|
|
_Py_CODEUNIT *close_loop_instr;
|
|
|
|
|
_Py_CODEUNIT *jump_backward_instr;
|
|
|
|
|
} _PyJitTracerInitialState;
|
|
|
|
|
|
|
|
|
|
typedef struct _PyJitTracerPreviousState {
|
|
|
|
|
int instr_oparg;
|
|
|
|
|
int instr_stacklevel;
|
|
|
|
|
_Py_CODEUNIT *instr;
|
|
|
|
|
PyCodeObject *instr_code; // Strong
|
|
|
|
|
struct _PyInterpreterFrame *instr_frame;
|
2026-02-02 16:57:04 +00:00
|
|
|
PyObject *recorded_value; // Strong, may be NULL
|
2026-01-22 10:55:49 +00:00
|
|
|
} _PyJitTracerPreviousState;
|
|
|
|
|
|
|
|
|
|
typedef struct _PyJitTracerTranslatorState {
|
|
|
|
|
int jump_backward_seen;
|
|
|
|
|
} _PyJitTracerTranslatorState;
|
|
|
|
|
|
|
|
|
|
typedef struct _PyJitTracerState {
|
|
|
|
|
bool is_tracing;
|
|
|
|
|
_PyJitTracerInitialState initial_state;
|
|
|
|
|
_PyJitTracerPreviousState prev_state;
|
|
|
|
|
_PyJitTracerTranslatorState translator_state;
|
|
|
|
|
JitOptContext opt_context;
|
|
|
|
|
_PyJitUopBuffer code_buffer;
|
|
|
|
|
_PyJitUopBuffer out_buffer;
|
|
|
|
|
_PyUOpInstruction uop_array[2 * UOP_MAX_TRACE_LENGTH];
|
|
|
|
|
} _PyJitTracerState;
|
|
|
|
|
|
2024-06-26 13:54:03 +02:00
|
|
|
typedef struct _PyExecutorLinkListNode {
|
|
|
|
|
struct _PyExecutorObject *next;
|
|
|
|
|
struct _PyExecutorObject *previous;
|
|
|
|
|
} _PyExecutorLinkListNode;
|
|
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
|
uint8_t opcode;
|
|
|
|
|
uint8_t oparg;
|
2025-12-11 10:32:52 +00:00
|
|
|
uint8_t valid;
|
|
|
|
|
uint8_t chain_depth; // Must be big enough for MAX_CHAIN_DEPTH - 1.
|
2026-01-14 18:27:33 +08:00
|
|
|
bool cold;
|
2025-12-23 17:19:34 +00:00
|
|
|
uint8_t pending_deletion;
|
2025-12-11 10:32:52 +00:00
|
|
|
int32_t index; // Index of ENTER_EXECUTOR (if code isn't NULL, below).
|
2026-03-16 23:58:18 +08:00
|
|
|
int32_t bloom_array_idx; // Index in interp->executor_blooms/executor_ptrs.
|
|
|
|
|
_PyExecutorLinkListNode links; // Used by deletion list.
|
2024-06-26 13:54:03 +02:00
|
|
|
PyCodeObject *code; // Weak (NULL if no corresponding ENTER_EXECUTOR).
|
|
|
|
|
} _PyVMData;
|
|
|
|
|
|
2025-08-01 16:26:07 +01:00
|
|
|
typedef struct _PyExitData {
|
2024-06-26 13:54:03 +02:00
|
|
|
uint32_t target;
|
2025-12-11 10:32:52 +00:00
|
|
|
uint16_t index:12;
|
|
|
|
|
uint16_t stack_cache:2;
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
uint16_t is_dynamic:1;
|
|
|
|
|
uint16_t is_control_flow:1;
|
2024-06-26 13:54:03 +02:00
|
|
|
_Py_BackoffCounter temperature;
|
2025-05-04 10:05:35 +01:00
|
|
|
struct _PyExecutorObject *executor;
|
2024-06-26 13:54:03 +02:00
|
|
|
} _PyExitData;
|
|
|
|
|
|
|
|
|
|
typedef struct _PyExecutorObject {
|
|
|
|
|
PyObject_VAR_HEAD
|
|
|
|
|
const _PyUOpInstruction *trace;
|
|
|
|
|
_PyVMData vm_data; /* Used by the VM, but opaque to the optimizer */
|
|
|
|
|
uint32_t exit_count;
|
|
|
|
|
uint32_t code_size;
|
|
|
|
|
size_t jit_size;
|
|
|
|
|
void *jit_code;
|
|
|
|
|
_PyExitData exits[1];
|
|
|
|
|
} _PyExecutorObject;
|
|
|
|
|
|
|
|
|
|
// Export for '_opcode' shared extension (JIT compiler).
|
|
|
|
|
PyAPI_FUNC(_PyExecutorObject*) _Py_GetExecutor(PyCodeObject *code, int offset);
|
|
|
|
|
|
2026-03-16 23:58:18 +08:00
|
|
|
int _Py_ExecutorInit(_PyExecutorObject *, const _PyBloomFilter *);
|
2024-06-26 13:54:03 +02:00
|
|
|
void _Py_ExecutorDetach(_PyExecutorObject *);
|
|
|
|
|
PyAPI_FUNC(void) _Py_Executor_DependsOn(_PyExecutorObject *executor, void *obj);
|
|
|
|
|
|
2026-03-19 00:58:14 +08:00
|
|
|
/* We use a bloomfilter with k = 6, m = 256
|
|
|
|
|
* The choice of k and the following constants
|
|
|
|
|
* could do with a more rigorous analysis,
|
|
|
|
|
* but here is a simple analysis:
|
|
|
|
|
*
|
|
|
|
|
* We want to keep the false positive rate low.
|
|
|
|
|
* For n = 5 (a trace depends on 5 objects),
|
|
|
|
|
* we expect 30 bits set, giving a false positive
|
|
|
|
|
* rate of (30/256)**6 == 2.5e-6 which is plenty
|
|
|
|
|
* good enough.
|
|
|
|
|
*
|
|
|
|
|
* However with n = 10 we expect 60 bits set (worst case),
|
|
|
|
|
* giving a false positive of (60/256)**6 == 0.0001
|
|
|
|
|
*
|
|
|
|
|
* We choose k = 6, rather than a higher number as
|
|
|
|
|
* it means the false positive rate grows slower for high n.
|
|
|
|
|
*
|
|
|
|
|
* n = 5, k = 6 => fp = 2.6e-6
|
|
|
|
|
* n = 5, k = 8 => fp = 3.5e-7
|
|
|
|
|
* n = 10, k = 6 => fp = 1.6e-4
|
|
|
|
|
* n = 10, k = 8 => fp = 0.9e-4
|
|
|
|
|
* n = 15, k = 6 => fp = 0.18%
|
|
|
|
|
* n = 15, k = 8 => fp = 0.23%
|
|
|
|
|
* n = 20, k = 6 => fp = 1.1%
|
|
|
|
|
* n = 20, k = 8 => fp = 2.3%
|
|
|
|
|
*
|
|
|
|
|
* The above analysis assumes perfect hash functions,
|
|
|
|
|
* but those don't exist, so the real false positive
|
|
|
|
|
* rates may be worse.
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#define _Py_BLOOM_FILTER_K 6
|
|
|
|
|
#define _Py_BLOOM_FILTER_SEED 20221211
|
|
|
|
|
|
|
|
|
|
static inline uint64_t
|
|
|
|
|
address_to_hash(void *ptr) {
|
|
|
|
|
assert(ptr != NULL);
|
|
|
|
|
uint64_t uhash = _Py_BLOOM_FILTER_SEED;
|
|
|
|
|
uintptr_t addr = (uintptr_t)ptr;
|
|
|
|
|
for (int i = 0; i < SIZEOF_VOID_P; i++) {
|
|
|
|
|
uhash ^= addr & 255;
|
|
|
|
|
uhash *= (uint64_t)PyHASH_MULTIPLIER;
|
|
|
|
|
addr >>= 8;
|
|
|
|
|
}
|
|
|
|
|
return uhash;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
_Py_BloomFilter_Init(_PyBloomFilter *bloom)
|
|
|
|
|
{
|
|
|
|
|
for (int i = 0; i < _Py_BLOOM_FILTER_WORDS; i++) {
|
|
|
|
|
bloom->bits[i] = 0;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline void
|
|
|
|
|
_Py_BloomFilter_Add(_PyBloomFilter *bloom, void *ptr)
|
|
|
|
|
{
|
|
|
|
|
uint64_t hash = address_to_hash(ptr);
|
|
|
|
|
assert(_Py_BLOOM_FILTER_K <= 8);
|
|
|
|
|
for (int i = 0; i < _Py_BLOOM_FILTER_K; i++) {
|
|
|
|
|
uint8_t bits = hash & 255;
|
|
|
|
|
bloom->bits[bits >> _Py_BLOOM_FILTER_WORD_SHIFT] |=
|
|
|
|
|
(_Py_bloom_filter_word_t)1 << (bits & (_Py_BLOOM_FILTER_BITS_PER_WORD - 1));
|
|
|
|
|
hash >>= 8;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
|
bloom_filter_may_contain(const _PyBloomFilter *bloom, const _PyBloomFilter *hashes)
|
|
|
|
|
{
|
|
|
|
|
for (int i = 0; i < _Py_BLOOM_FILTER_WORDS; i++) {
|
|
|
|
|
if ((bloom->bits[i] & hashes->bits[i]) != hashes->bits[i]) {
|
|
|
|
|
return false;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2024-06-26 13:54:03 +02:00
|
|
|
#define _Py_MAX_ALLOWED_BUILTINS_MODIFICATIONS 3
|
|
|
|
|
#define _Py_MAX_ALLOWED_GLOBALS_MODIFICATIONS 6
|
|
|
|
|
|
|
|
|
|
#ifdef _Py_TIER2
|
|
|
|
|
PyAPI_FUNC(void) _Py_Executors_InvalidateDependency(PyInterpreterState *interp, void *obj, int is_invalidation);
|
|
|
|
|
PyAPI_FUNC(void) _Py_Executors_InvalidateAll(PyInterpreterState *interp, int is_invalidation);
|
2024-09-26 17:35:42 -07:00
|
|
|
PyAPI_FUNC(void) _Py_Executors_InvalidateCold(PyInterpreterState *interp);
|
|
|
|
|
|
2024-06-26 13:54:03 +02:00
|
|
|
#else
|
|
|
|
|
# define _Py_Executors_InvalidateDependency(A, B, C) ((void)0)
|
|
|
|
|
# define _Py_Executors_InvalidateAll(A, B) ((void)0)
|
2024-09-26 17:35:42 -07:00
|
|
|
|
2024-06-26 13:54:03 +02:00
|
|
|
#endif
|
|
|
|
|
|
2024-09-26 17:35:42 -07:00
|
|
|
// Used as the threshold to trigger executor invalidation when
|
2025-10-27 18:37:37 +02:00
|
|
|
// executor_creation_counter is greater than this value.
|
|
|
|
|
// This value is arbitrary and was not optimized.
|
|
|
|
|
#define JIT_CLEANUP_THRESHOLD 1000
|
2024-06-26 13:54:03 +02:00
|
|
|
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
int _Py_uop_analyze_and_optimize(
|
2026-01-09 03:38:21 +08:00
|
|
|
_PyThreadStateImpl *tstate,
|
2026-01-22 10:55:49 +00:00
|
|
|
_PyUOpInstruction *input, int trace_len, int curr_stackentries,
|
|
|
|
|
_PyUOpInstruction *output, _PyBloomFilter *dependencies);
|
2023-08-16 02:04:17 +08:00
|
|
|
|
2023-10-29 13:53:25 -07:00
|
|
|
extern PyTypeObject _PyUOpExecutor_Type;
|
2023-08-16 02:04:17 +08:00
|
|
|
|
2024-02-27 10:51:26 +00:00
|
|
|
|
2024-05-10 18:20:12 +02:00
|
|
|
#define UOP_FORMAT_TARGET 0
|
2024-07-01 13:17:40 -07:00
|
|
|
#define UOP_FORMAT_JUMP 1
|
2024-05-10 18:20:12 +02:00
|
|
|
|
|
|
|
|
static inline uint32_t uop_get_target(const _PyUOpInstruction *inst)
|
|
|
|
|
{
|
|
|
|
|
assert(inst->format == UOP_FORMAT_TARGET);
|
|
|
|
|
return inst->target;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline uint16_t uop_get_jump_target(const _PyUOpInstruction *inst)
|
|
|
|
|
{
|
|
|
|
|
assert(inst->format == UOP_FORMAT_JUMP);
|
|
|
|
|
return inst->jump_target;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline uint16_t uop_get_error_target(const _PyUOpInstruction *inst)
|
|
|
|
|
{
|
|
|
|
|
assert(inst->format != UOP_FORMAT_TARGET);
|
|
|
|
|
return inst->error_target;
|
|
|
|
|
}
|
|
|
|
|
|
2025-06-17 23:25:53 +08:00
|
|
|
|
|
|
|
|
#define REF_IS_BORROWED 1
|
2026-03-23 00:57:23 +08:00
|
|
|
#define REF_IS_UNIQUE 2
|
|
|
|
|
#define REF_IS_INVALID 3
|
2026-01-17 23:20:35 +08:00
|
|
|
#define REF_TAG_BITS 3
|
2025-06-17 23:25:53 +08:00
|
|
|
|
2026-03-23 00:57:23 +08:00
|
|
|
#define REF_GET_TAG(x) ((uintptr_t)(x) & (REF_TAG_BITS))
|
|
|
|
|
#define REF_CLEAR_TAG(x) ((uintptr_t)(x) & (~REF_TAG_BITS))
|
|
|
|
|
|
2026-01-17 23:20:35 +08:00
|
|
|
#define JIT_BITS_TO_PTR_MASKED(REF) ((JitOptSymbol *)(((REF).bits) & (~REF_TAG_BITS)))
|
2025-06-17 23:25:53 +08:00
|
|
|
|
|
|
|
|
static inline JitOptSymbol *
|
|
|
|
|
PyJitRef_Unwrap(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
return JIT_BITS_TO_PTR_MASKED(ref);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
bool _Py_uop_symbol_is_immortal(JitOptSymbol *sym);
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_Wrap(JitOptSymbol *sym)
|
|
|
|
|
{
|
|
|
|
|
return (JitOptRef){.bits=(uintptr_t)sym};
|
|
|
|
|
}
|
|
|
|
|
|
2026-01-17 23:20:35 +08:00
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_WrapInvalid(void *ptr)
|
|
|
|
|
{
|
2026-03-23 00:57:23 +08:00
|
|
|
return (JitOptRef){.bits = REF_CLEAR_TAG((uintptr_t)ptr) | REF_IS_INVALID};
|
2026-01-17 23:20:35 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
|
PyJitRef_IsInvalid(JitOptRef ref)
|
|
|
|
|
{
|
2026-03-23 00:57:23 +08:00
|
|
|
return REF_GET_TAG(ref.bits) == REF_IS_INVALID;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_MakeUnique(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
return (JitOptRef){ REF_CLEAR_TAG(ref.bits) | REF_IS_UNIQUE };
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
|
PyJitRef_IsUnique(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
return REF_GET_TAG(ref.bits) == REF_IS_UNIQUE;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_StripBorrowInfo(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
if (PyJitRef_IsUnique(ref)) {
|
|
|
|
|
return ref;
|
|
|
|
|
}
|
|
|
|
|
return (JitOptRef){ .bits = REF_CLEAR_TAG(ref.bits) };
|
2026-01-17 23:20:35 +08:00
|
|
|
}
|
|
|
|
|
|
2025-09-04 02:05:06 +08:00
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_StripReferenceInfo(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
return PyJitRef_Wrap(PyJitRef_Unwrap(ref));
|
|
|
|
|
}
|
|
|
|
|
|
2026-03-23 00:57:23 +08:00
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_RemoveUnique(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
if (PyJitRef_IsUnique(ref)) {
|
|
|
|
|
ref = PyJitRef_StripReferenceInfo(ref);
|
|
|
|
|
}
|
|
|
|
|
return ref;
|
|
|
|
|
}
|
|
|
|
|
|
2025-06-17 23:25:53 +08:00
|
|
|
static inline JitOptRef
|
|
|
|
|
PyJitRef_Borrow(JitOptRef ref)
|
|
|
|
|
{
|
2026-03-23 00:57:23 +08:00
|
|
|
return (JitOptRef){ .bits = REF_CLEAR_TAG(ref.bits) | REF_IS_BORROWED };
|
2025-06-17 23:25:53 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static const JitOptRef PyJitRef_NULL = {.bits = REF_IS_BORROWED};
|
|
|
|
|
|
|
|
|
|
static inline bool
|
|
|
|
|
PyJitRef_IsNull(JitOptRef ref)
|
|
|
|
|
{
|
|
|
|
|
return ref.bits == PyJitRef_NULL.bits;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static inline int
|
|
|
|
|
PyJitRef_IsBorrowed(JitOptRef ref)
|
|
|
|
|
{
|
2026-03-23 00:57:23 +08:00
|
|
|
return REF_GET_TAG(ref.bits) == REF_IS_BORROWED;
|
2025-06-17 23:25:53 +08:00
|
|
|
}
|
2024-02-27 10:51:26 +00:00
|
|
|
|
2025-06-17 23:25:53 +08:00
|
|
|
extern bool _Py_uop_sym_is_null(JitOptRef sym);
|
|
|
|
|
extern bool _Py_uop_sym_is_not_null(JitOptRef sym);
|
|
|
|
|
extern bool _Py_uop_sym_is_const(JitOptContext *ctx, JitOptRef sym);
|
|
|
|
|
extern PyObject *_Py_uop_sym_get_const(JitOptContext *ctx, JitOptRef sym);
|
|
|
|
|
extern JitOptRef _Py_uop_sym_new_unknown(JitOptContext *ctx);
|
|
|
|
|
extern JitOptRef _Py_uop_sym_new_not_null(JitOptContext *ctx);
|
|
|
|
|
extern JitOptRef _Py_uop_sym_new_type(
|
2025-01-20 15:49:15 +00:00
|
|
|
JitOptContext *ctx, PyTypeObject *typ);
|
2025-06-19 11:10:29 +01:00
|
|
|
|
2025-06-17 23:25:53 +08:00
|
|
|
extern JitOptRef _Py_uop_sym_new_const(JitOptContext *ctx, PyObject *const_val);
|
2025-06-27 19:37:44 +08:00
|
|
|
extern JitOptRef _Py_uop_sym_new_const_steal(JitOptContext *ctx, PyObject *const_val);
|
|
|
|
|
bool _Py_uop_sym_is_safe_const(JitOptContext *ctx, JitOptRef sym);
|
|
|
|
|
_PyStackRef _Py_uop_sym_get_const_as_stackref(JitOptContext *ctx, JitOptRef sym);
|
2025-06-17 23:25:53 +08:00
|
|
|
extern JitOptRef _Py_uop_sym_new_null(JitOptContext *ctx);
|
|
|
|
|
extern bool _Py_uop_sym_has_type(JitOptRef sym);
|
|
|
|
|
extern bool _Py_uop_sym_matches_type(JitOptRef sym, PyTypeObject *typ);
|
|
|
|
|
extern bool _Py_uop_sym_matches_type_version(JitOptRef sym, unsigned int version);
|
|
|
|
|
extern void _Py_uop_sym_set_null(JitOptContext *ctx, JitOptRef sym);
|
|
|
|
|
extern void _Py_uop_sym_set_non_null(JitOptContext *ctx, JitOptRef sym);
|
|
|
|
|
extern void _Py_uop_sym_set_type(JitOptContext *ctx, JitOptRef sym, PyTypeObject *typ);
|
|
|
|
|
extern bool _Py_uop_sym_set_type_version(JitOptContext *ctx, JitOptRef sym, unsigned int version);
|
|
|
|
|
extern void _Py_uop_sym_set_const(JitOptContext *ctx, JitOptRef sym, PyObject *const_val);
|
|
|
|
|
extern bool _Py_uop_sym_is_bottom(JitOptRef sym);
|
|
|
|
|
extern int _Py_uop_sym_truthiness(JitOptContext *ctx, JitOptRef sym);
|
|
|
|
|
extern PyTypeObject *_Py_uop_sym_get_type(JitOptRef sym);
|
|
|
|
|
extern JitOptRef _Py_uop_sym_new_tuple(JitOptContext *ctx, int size, JitOptRef *args);
|
2025-09-03 23:42:26 +09:00
|
|
|
extern JitOptRef _Py_uop_sym_tuple_getitem(JitOptContext *ctx, JitOptRef sym, Py_ssize_t item);
|
|
|
|
|
extern Py_ssize_t _Py_uop_sym_tuple_length(JitOptRef sym);
|
2025-06-17 23:25:53 +08:00
|
|
|
extern JitOptRef _Py_uop_sym_new_truthiness(JitOptContext *ctx, JitOptRef value, bool truthy);
|
2025-06-19 11:10:29 +01:00
|
|
|
extern bool _Py_uop_sym_is_compact_int(JitOptRef sym);
|
|
|
|
|
extern JitOptRef _Py_uop_sym_new_compact_int(JitOptContext *ctx);
|
|
|
|
|
extern void _Py_uop_sym_set_compact_int(JitOptContext *ctx, JitOptRef sym);
|
2026-01-22 17:37:45 +08:00
|
|
|
extern JitOptRef _Py_uop_sym_new_predicate(JitOptContext *ctx, JitOptRef lhs_ref, JitOptRef rhs_ref, JitOptPredicateKind kind);
|
|
|
|
|
extern void _Py_uop_sym_apply_predicate_narrowing(JitOptContext *ctx, JitOptRef sym, bool branch_is_true);
|
2026-02-05 08:58:41 +00:00
|
|
|
extern void _Py_uop_sym_set_recorded_value(JitOptContext *ctx, JitOptRef sym, PyObject *value);
|
|
|
|
|
extern void _Py_uop_sym_set_recorded_type(JitOptContext *ctx, JitOptRef sym, PyTypeObject *type);
|
|
|
|
|
extern void _Py_uop_sym_set_recorded_gen_func(JitOptContext *ctx, JitOptRef ref, PyFunctionObject *value);
|
|
|
|
|
extern PyCodeObject *_Py_uop_sym_get_probable_func_code(JitOptRef sym);
|
|
|
|
|
extern PyObject *_Py_uop_sym_get_probable_value(JitOptRef sym);
|
2026-03-03 09:58:38 +09:00
|
|
|
extern PyTypeObject *_Py_uop_sym_get_probable_type(JitOptRef sym);
|
2026-02-19 11:52:57 +00:00
|
|
|
extern JitOptRef *_Py_uop_sym_set_stack_depth(JitOptContext *ctx, int stack_depth, JitOptRef *current_sp);
|
2026-03-20 20:26:41 +08:00
|
|
|
extern uint32_t _Py_uop_sym_get_func_version(JitOptRef ref);
|
|
|
|
|
bool _Py_uop_sym_set_func_version(JitOptContext *ctx, JitOptRef ref, uint32_t version);
|
2025-01-20 15:49:15 +00:00
|
|
|
|
2026-02-19 11:52:57 +00:00
|
|
|
extern void _Py_uop_abstractcontext_init(JitOptContext *ctx, _PyBloomFilter *dependencies);
|
2025-01-20 15:49:15 +00:00
|
|
|
extern void _Py_uop_abstractcontext_fini(JitOptContext *ctx);
|
2024-02-27 13:25:02 +00:00
|
|
|
|
|
|
|
|
extern _Py_UOpsAbstractFrame *_Py_uop_frame_new(
|
2025-01-20 15:49:15 +00:00
|
|
|
JitOptContext *ctx,
|
2024-02-27 10:51:26 +00:00
|
|
|
PyCodeObject *co,
|
2025-06-17 23:25:53 +08:00
|
|
|
JitOptRef *args,
|
2024-06-08 05:41:45 -04:00
|
|
|
int arg_len);
|
2026-02-05 08:58:41 +00:00
|
|
|
|
|
|
|
|
extern _Py_UOpsAbstractFrame *_Py_uop_frame_new_from_symbol(
|
|
|
|
|
JitOptContext *ctx,
|
|
|
|
|
JitOptRef callable,
|
|
|
|
|
JitOptRef *args,
|
|
|
|
|
int arg_len);
|
|
|
|
|
|
2026-02-19 11:52:57 +00:00
|
|
|
extern int _Py_uop_frame_pop(JitOptContext *ctx, PyCodeObject *co);
|
2024-02-27 10:51:26 +00:00
|
|
|
|
2024-02-27 13:25:02 +00:00
|
|
|
PyAPI_FUNC(PyObject *) _Py_uop_symbols_test(PyObject *self, PyObject *ignored);
|
2024-02-27 10:51:26 +00:00
|
|
|
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
PyAPI_FUNC(int) _PyOptimizer_Optimize(_PyInterpreterFrame *frame, PyThreadState *tstate);
|
2024-02-29 08:11:28 -08:00
|
|
|
|
2025-08-01 16:26:07 +01:00
|
|
|
static inline _PyExecutorObject *_PyExecutor_FromExit(_PyExitData *exit)
|
|
|
|
|
{
|
|
|
|
|
_PyExitData *exit0 = exit - exit->index;
|
|
|
|
|
return (_PyExecutorObject *)(((char *)exit0) - offsetof(_PyExecutorObject, exits));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
extern _PyExecutorObject *_PyExecutor_GetColdExecutor(void);
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
extern _PyExecutorObject *_PyExecutor_GetColdDynamicExecutor(void);
|
2025-08-01 16:26:07 +01:00
|
|
|
|
|
|
|
|
PyAPI_FUNC(void) _PyExecutor_ClearExit(_PyExitData *exit);
|
|
|
|
|
|
|
|
|
|
extern void _PyExecutor_Free(_PyExecutorObject *self);
|
|
|
|
|
|
2024-12-13 11:00:00 +00:00
|
|
|
PyAPI_FUNC(int) _PyDumpExecutors(FILE *out);
|
2025-05-04 10:05:35 +01:00
|
|
|
#ifdef _Py_TIER2
|
2026-01-10 19:15:48 +08:00
|
|
|
PyAPI_FUNC(void) _Py_ClearExecutorDeletionList(PyInterpreterState *interp);
|
2025-05-04 10:05:35 +01:00
|
|
|
#endif
|
2024-12-13 11:00:00 +00:00
|
|
|
|
2026-01-17 21:31:38 +08:00
|
|
|
PyAPI_FUNC(int) _PyJit_translate_single_bytecode_to_trace(PyThreadState *tstate, _PyInterpreterFrame *frame, _Py_CODEUNIT *next_instr, int stop_tracing_opcode);
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
|
2025-11-18 13:31:48 +00:00
|
|
|
PyAPI_FUNC(int)
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
_PyJit_TryInitializeTracing(PyThreadState *tstate, _PyInterpreterFrame *frame,
|
|
|
|
|
_Py_CODEUNIT *curr_instr, _Py_CODEUNIT *start_instr,
|
2026-02-02 16:57:04 +00:00
|
|
|
_Py_CODEUNIT *close_loop_instr, _PyStackRef *stack_pointer, int chain_depth, _PyExitData *exit,
|
2026-01-10 19:15:48 +08:00
|
|
|
int oparg, _PyExecutorObject *current_executor);
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
|
2026-01-17 21:31:38 +08:00
|
|
|
PyAPI_FUNC(void) _PyJit_FinalizeTracing(PyThreadState *tstate, int err);
|
2026-03-17 00:18:59 +08:00
|
|
|
PyAPI_FUNC(bool) _PyJit_EnterExecutorShouldStopTracing(int og_opcode);
|
|
|
|
|
|
2026-02-05 08:58:41 +00:00
|
|
|
void _PyPrintExecutor(_PyExecutorObject *executor, const _PyUOpInstruction *marker);
|
2026-01-10 03:00:49 +08:00
|
|
|
void _PyJit_TracerFree(_PyThreadStateImpl *_tstate);
|
gh-139109: A new tracing JIT compiler frontend for CPython (GH-140310)
This PR changes the current JIT model from trace projection to trace recording. Benchmarking: better pyperformance (about 1.7% overall) geomean versus current https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251108-3.15.0a1%2B-7e2bc1d-JIT/bm-20251108-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-7e2bc1d-vs-base.svg, 100% faster Richards on the most improved benchmark versus the current JIT. Slowdown of about 10-15% on the worst benchmark versus the current JIT. **Note: the fastest version isn't the one merged, as it relies on fixing bugs in the specializing interpreter, which is left to another PR**. The speedup in the merged version is about 1.1%. https://raw.githubusercontent.com/facebookexperimental/free-threading-benchmarking/refs/heads/main/results/bm-20251112-3.15.0a1%2B-f8a764a-JIT/bm-20251112-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-f8a764a-vs-base.svg
Stats: 50% more uops executed, 30% more traces entered the last time we ran them. It also suggests our trace lengths for a real trace recording JIT are too short, as a lot of trace too long aborts https://github.com/facebookexperimental/free-threading-benchmarking/blob/main/results/bm-20251023-3.15.0a1%2B-eb73378-CLANG%2CJIT/bm-20251023-vultr-x86_64-Fidget%252dSpinner-tracing_jit-3.15.0a1%2B-eb73378-pystats-vs-base.md .
This new JIT frontend is already able to record/execute significantly more instructions than the previous JIT frontend. In this PR, we are now able to record through custom dunders, simple object creation, generators, etc. None of these were done by the old JIT frontend. Some custom dunders uops were discovered to be broken as part of this work gh-140277
The optimizer stack space check is disabled, as it's no longer valid to deal with underflow.
Pros:
* Ignoring the generated tracer code as it's automatically created, this is only additional 1k lines of code. The maintenance burden is handled by the DSL and code generator.
* `optimizer.c` is now significantly simpler, as we don't have to do strange things to recover the bytecode from a trace.
* The new JIT frontend is able to handle a lot more control-flow than the old one.
* Tracing is very low overhead. We use the tail calling interpreter/computed goto interpreter to switch between tracing mode and non-tracing mode. I call this mechanism dual dispatch, as we have two dispatch tables dispatching to each other. Specialization is still enabled while tracing.
* Better handling of polymorphism. We leverage the specializing interpreter for this.
Cons:
* (For now) requires tail calling interpreter or computed gotos. This means no Windows JIT for now :(. Not to fret, tail calling is coming soon to Windows though https://github.com/python/cpython/pull/139962
Design:
* After each instruction, the `record_previous_inst` function/label is executed. This does as the name suggests.
* The tracing interpreter lowers bytecode to uops directly so that it can obtain "fresh" values at the point of lowering.
* The tracing version behaves nearly identical to the normal interpreter, in fact it even has specialization! This allows it to run without much of a slowdown when tracing. The actual cost of tracing is only a function call and writes to memory.
* The tracing interpreter uses the specializing interpreter's deopt to naturally form the side exit chains. This allows it to side exit chain effectively, without repeating much code. We force a re-specializing when tracing a deopt.
* The tracing interpreter can even handle goto errors/exceptions, but I chose to disable them for now as it's not tested.
* Because we do not share interpreter dispatch, there is should be no significant slowdown to the original specializing interpreter on tailcall and computed got with JIT disabled. With JIT enabled, there might be a slowdown in the form of the JIT trying to trace.
* Things that could have dynamic instruction pointer effects are guarded on. The guard deopts to a new instruction --- `_DYNAMIC_EXIT`.
2025-11-14 02:08:32 +08:00
|
|
|
|
2026-02-02 16:57:04 +00:00
|
|
|
#ifdef _Py_TIER2
|
|
|
|
|
typedef void (*_Py_RecordFuncPtr)(_PyInterpreterFrame *frame, _PyStackRef *stackpointer, int oparg, PyObject **recorded_value);
|
|
|
|
|
PyAPI_DATA(const _Py_RecordFuncPtr) _PyOpcode_RecordFunctions[];
|
|
|
|
|
PyAPI_DATA(const uint8_t) _PyOpcode_RecordFunctionIndices[256];
|
|
|
|
|
#endif
|
|
|
|
|
|
2023-08-16 02:04:17 +08:00
|
|
|
#ifdef __cplusplus
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
#endif /* !Py_INTERNAL_OPTIMIZER_H */
|