Feature or enhancement
Proposal:
The current JIT recorder generation logic tends to conflate the family source recording layout with the specific consumer layout, leading to the following issues:
- The set of recorders for members within a family is not explicitly modeled by the analyzer, so the generator must infer the recording semantics for family members on its own.
- When the base opcode and specialized opcode record the same slot in different formats, the generator may choose the specialized recorder as the family source slot.
- If the family source slot selects a derived value, such as
_RECORD_TOS_TYPE, the base opcode’s raw recorder _RECORD_TOS must be converted back from a type to a raw object; this process is irreversible and does not reflect the true capabilities of runtime transforms.
- Runtime transform helpers are hand-coded in
Python/optimizer.c, making them prone to drift from the recorder uop body.
- The transform dispatcher may generate helpers for recorders that are not actually used by any slot map, increasing dead branches and maintenance overhead in the generated code.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs
Feature or enhancement
Proposal:
The current JIT recorder generation logic tends to conflate the family source recording layout with the specific consumer layout, leading to the following issues:
_RECORD_TOS_TYPE, the base opcode’s raw recorder_RECORD_TOSmust be converted back from a type to a raw object; this process is irreversible and does not reflect the true capabilities of runtime transforms.Python/optimizer.c, making them prone to drift from the recorder uop body.Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
Linked PRs