Skip to content

Constant evaluate/propagate pure ops automatically #132732

Closed

Description

@Fidget-Spinner

Feature or enhancement

Proposal:

@brandtbucher pointed out that we could automatically evaluate pure ops in the JIT.

Back when I originally envisioned this in the JIT optimizer, it was way simpler. Right now we have stackrefs which complicate things a little.

The main idea is that fully pure bytecodes can just run their body in the JIT optimizer, allowing for automatic constant prop/evaluation. This also cuts down code duplication and also the amount of human error from manually writing constant propagation code.

We'd have to replace all the stackref functions with the appropriate sym accessing functions, either through macros or the cases generator.

Has this already been discussed elsewhere?

No response given

Links to previous discussion of this feature:

No response

Linked PRs

Activity

  1. brandtbucher commented on Apr 24, 2025

    @brandtbucher
    Member

    Two follow-ups to this:

    • pure_guard, which evaluates guards in the optimizer and removes the op if it doesn't deopt.
    • Wholesale replacing of pure instructions with _POP_TOP_*_LOAD_CONST_INLINE_BORROW or whatever if the result is immortal.
    • Replacing all constant outputs like above, even if they're not immortal (requires executors to hold references to this new constant pool).
  2. added a commit that references this issue on Jun 27, 2025
  3. added a commit that references this issue on Jun 27, 2025
  4. added a commit that references this issue on Jun 27, 2025
  5. brandtbucher commented on Jun 27, 2025

    @brandtbucher
    Member

    Just talked with @savannahostrowski, she's going to modify the cases generator to replace the entire instruction when constant evaluation produces an immortal value.

  6. added a commit that references this issue on Jun 28, 2025
  7. added 3 commits that reference this issue on Jul 11, 2025
  8. added 2 commits that reference this issue on Jul 12, 2025
  9. 4 remaining items

  10. added a commit that references this issue on Aug 4, 2025
  11. added 4 commits that reference this issue on Aug 19, 2025
  12. added a commit that references this issue on Sep 15, 2025
  13. savannahostrowski commented on Sep 15, 2025

    @savannahostrowski
    Member

    @Fidget-Spinner @brandtbucher Are we good to close this out after #137577 or is there more I should work on here? 😈

  14. Fidget-Spinner commented on Sep 15, 2025

    @Fidget-Spinner
    MemberAuthor

    @savannahostrowski we still have this left #136048 . The problem is with these constant propagation, the optimizer can now error, and we need to handle that properly.

  15. added a commit that references this issue on Sep 15, 2025
  16. savannahostrowski commented on Sep 15, 2025

    @savannahostrowski
    Member

    Ah! I missed that. I'll reassign this issue to you, and you can close it out when that lands.

  17. added a commit that references this issue on Sep 15, 2025
  18. Fidget-Spinner commented on Sep 15, 2025

    @Fidget-Spinner
    MemberAuthor

    This is done! Thanks Savannah!

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

Metadata

Metadata

Labels

interpreter-core(Objects, Python, Grammar, and Parser dirs)topic-JITtype-featureA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions