Skip to content

JIT assembly optimizer leaves some redundant branches #139757

Closed

Description

@markshannon

For AArch64 emit__GUARD_IS_TRUE_POP produces the following assembly code:

...
14: 54000041 b.ne 0x1c <_JIT_ENTRY+0x1c>
18: 14000002 b 0x20 <_JIT_ENTRY+0x20>
1c: 14000000 b 0x1c <_JIT_ENTRY+0x1c>
000000000000001c: R_AARCH64_JUMP26 _JIT_JUMP_TARGET

but it should, ideally, emit this:

14: 54000041 b.ne 0x14 <_JIT_ENTRY+0x14>
000000000000001c: R_AARCH64_CONDBR19 _JIT_JUMP_TARGET

This doesn't seem to be an issue for x86, possibly due to the way Clang is setup for AArch64, possibly just an artefact of llvm's code gen.
Either way, rather than rely on llvm eliminating these jumps we can do it in the JIT builder's assembly optimizer.
Currently we don't perform jump fusion, but it would be easy enough to do so.

Linked PRs

Activity

  1. added
    type-featureA feature request or enhancement
    performancePerformance or resource usage
    interpreter-core(Objects, Python, Grammar, and Parser dirs)
    and removed
    performancePerformance or resource usage
    on Oct 8, 2025
  2. added a commit that references this issue on Dec 4, 2025
  3. added a commit that references this issue on Dec 6, 2025
  4. added a commit that references this issue on Dec 8, 2025
  5. Fidget-Spinner commented on Dec 17, 2025

    @Fidget-Spinner
    Member

    The introduction of _remove_unreachable broke the JIT + FT builds on x86-64.

    I get this error:

    0.	Program arguments: clang-21 --target=x86_64-unknown-linux-gnu -c -o /tmp/tmpbw0scowv/_LOAD_ATTR_WITH_HINT_r11.o /tmp/tmpbw0scowv/_LOAD_ATTR_WITH_HINT_r11.s
    Stack dump without symbol names (ensure you have llvm-symbolizer in your PATH or set the environment var `LLVM_SYMBOLIZER_PATH` to point to it):
    
    

    Commenting it out fixes it.

  6. Fidget-Spinner commented on Dec 17, 2025

    @Fidget-Spinner
    Member

    Alright, I narrowed it down: for some stencils, there are more than one entry points, e.g. if PyStackRef_CLOSE is outlined, then a stencil may have two entry points (one _JIT_ENTRY, one PyStackRef_CLOSE).

    The problem with that is that we don't treat call PyStackRef_CLOSE as a jump to a live block. So this optimization breaks.

    A possible fix is to just treat all function entries as live.

  7. added a commit that references this issue on Dec 17, 2025
  8. added 5 commits that reference this issue on Jan 1, 2026
  9. added a commit that references this issue on Jan 4, 2026
  10. added 3 commits that reference this issue on Feb 15, 2026
  11. markshannon commented on Mar 23, 2026

    @markshannon
    MemberAuthor

    I think this is done

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

Metadata

Metadata

Assignees

No one assigned

    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