Skip to content

Conversation

@dianqk
Copy link
Member

@dianqk dianqk commented Jan 17, 2026

The test that is introduced in #128627 is a BBs order problem in LLVM. I'm not 100% confident in the following investigation, but I think this is presumably the result.

Per the following content that is mentioned at https://llvm.org/docs/KeyInstructionsDebugInfo.html:

DWARF provides a helpful tool the compiler can employ to mitigate this jumpiness, the is_stmt flag, which indicates that an instruction is a recommended breakpoint location. However, LLVM’s current approach to deciding is_stmt placement essentially reduces down to “is the associated line number different to the previous instruction’s?”.

Taking the example from https://rust.godbolt.org/z/GvToxj6vh. The partial assembly code with SimplifyComparisonIntegral is:

.LBB40_21:
        .loc    6 14 16 is_stmt 1
; RET = Ok(())
        mov     byte ptr [rsp + 79], 5
        .loc    6 0 0 is_stmt 0
        jmp     .LBB40_23
...
.LBB40_23:
        .loc    6 18 1 is_stmt 1
        lea     rdi, [rsp + 112]
; drop(number_str)
        call    qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL]
        jmp     .LBB40_27

without SimplifyComparisonIntegral:

.LBB40_22:
        .loc    6 14 16 is_stmt 1
; RET = Ok(())
        mov     byte ptr [rsp + 79], 5
        .loc    6 0 0 is_stmt 0
        jmp     .LBB40_27
...
.LBB40_26:
        .loc    6 18 2 is_stmt 0
        mov     al, byte ptr [rsp + 79]
        .loc    6 18 2 epilogue_begin
        add     rsp, 360
        .cfi_def_cfa_offset 8
        ret
.LBB40_27:
; same line number to the previous instruction, so don't place `is_stmt` flag.
; this flag is `is_stmt 0` that will follow the flag of `.LBB40_26`.
        .loc    6 18 1
        lea     rdi, [rsp + 112]
; drop(number_str)
        call    qword ptr [rip + core[270d1373c8f6a07d]::ptr::drop_in_place::<alloc[206d51544a00c3e8]::string::String>@GOTPCREL]
        jmp     .LBB40_26

GDB doesn't step to LBB40_27 due to is_stmt 0, so the next step is __rust_begin_short_backtrace. I have verified the new test works well with or without ``SimplifyComparisonIntegral`.

@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jan 17, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 17, 2026

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

@dianqk
Copy link
Member Author

dianqk commented Jan 17, 2026

@bors try jobs=x86_64-gnu-llvm-20-3

@rust-bors

This comment has been minimized.

rust-bors bot pushed a commit that referenced this pull request Jan 17, 2026
Refine dummy_span.rs test


try-job: x86_64-gnu-llvm-20-3
@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 17, 2026

☀️ Try build successful (CI)
Build commit: 2bedcc2 (2bedcc21077b29a1ea9612c18c021bd75bec1956, parent: 9f6cd6defbd7ef13f6777aa8e43b14d69f0a830a)

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

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants