Skip to content

gh-148285: Allow recording uops after specializing uops#148367

Closed
adityakrmishra wants to merge 0 commit intopython:mainfrom
adityakrmishra:fix-uop-recording-148285
Closed

gh-148285: Allow recording uops after specializing uops#148367
adityakrmishra wants to merge 0 commit intopython:mainfrom
adityakrmishra:fix-uop-recording-148285

Conversation

@adityakrmishra
Copy link
Copy Markdown

@adityakrmishra adityakrmishra commented Apr 11, 2026

The Issue:
Currently, analyzer.py uses a strict positional first = True check when validating macro structures. This strictly forces any uop with records_value == True to be at index 0, which prevents Tier 2 recording uops from safely trailing Tier 1 specializing uops.

The Fix:
Replaced the boolean first check with a state tracker (valid_recording_pos) in add_macro().

  • valid_recording_pos starts as True.
  • It remains True if the parsed part is a specializing uop (uop.properties.tier == 1).
  • It ignores CacheEffect and flush parts.
  • It flips to False for any other instruction, properly closing the gate.

This safely allows structures like:
macro(X) = _SPECIALIZE_X + _RECORD_TOS_TYPE + unused/1 + _X;

@python-cla-bot
Copy link
Copy Markdown

python-cla-bot bot commented Apr 11, 2026

All commit authors signed the Contributor License Agreement.

CLA signed

@bedevere-app
Copy link
Copy Markdown

bedevere-app bot commented Apr 11, 2026

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

@bedevere-app
Copy link
Copy Markdown

bedevere-app bot commented Apr 11, 2026

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

@Sacul0457
Copy link
Copy Markdown
Contributor

Hmm, while this does allow _RECORD uops to come after _SPECIALIZE uops, it also:

  • Allows _RECORD uops to come after non _SPECIALIZE uops since not all tier-1 uops are specializing.
  • No longer ensures both recording and specializing uops comes first

Example that violates both:

macro(LOAD_SUPER_ATTR) =
    _LOAD_SUPER_ATTR + // tier1 uop
    _RECORD_TOS_TYPE + 
    _SPECIALIZE_LOAD_SUPER_ATTR +
    _PUSH_NULL_CONDITIONAL;

BUT, you should wait for a core dev to review this as I may have misunderstood something.

@bedevere-app
Copy link
Copy Markdown

bedevere-app bot commented Apr 11, 2026

Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool.

If this change has little impact on Python users, wait for a maintainer to apply the skip news label instead.

@adityakrmishra
Copy link
Copy Markdown
Author

@Sacul0457 Good catch! You are entirely correct—my previous logic conflated all tier1 uops with specializing uops, which was too permissive. I also tangled up the Git history on this branch, so I have closed this PR and opened a clean one with a much stricter positional index check that specifically guards for SPECIALIZE prefixes.

The new PR is here: #148373
Thanks for the review

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Allow recording uops after specializing uops

2 participants