Skip to content

[DebugInfo] Use debug blocks in PhiExpansion rather than fragments#89471

Merged
Snowy1803 merged 4 commits into
swiftlang:mainfrom
Snowy1803:debug-bb-phi-expansion
May 29, 2026
Merged

[DebugInfo] Use debug blocks in PhiExpansion rather than fragments#89471
Snowy1803 merged 4 commits into
swiftlang:mainfrom
Snowy1803:debug-bb-phi-expansion

Conversation

@Snowy1803
Copy link
Copy Markdown
Member

@Snowy1803 Snowy1803 commented May 27, 2026

Includes #89470

When a struct is unwrapped in a phi node, only one field value can be salvaged at that point. Rather than using a fragment to express that, use a debug reconstruction basic block that sets all other fields to undef, which is an equivalent representation that supports existing debug reconstruction blocks.

Snowy1803 added 4 commits May 27, 2026 16:30
Similarly to the getCompleteVarInfo function in DebugValueInst, this
function returns a debug variable with location, scope and type.
Rather than defaulting to the SSA operand type, use getCompleteVarInfo
which does this already. Also removes the optional from the VarInfo.
When the vartype isn't allocated in the debug_value instruction, and
a debug reconstruction block is added to the instruction, the variable
type should default to the debug reconstruction's returned value's type,
rather than the SSA's operand's type.
When a struct is unwrapped in a phi node, only one field value can be
salvaged at that point. Rather than using a fragment to express that,
use a debug reconstruction basic block that sets all other fields to
undef, which is an equivalent representation that supports existing
debug reconstruction blocks.
@Snowy1803
Copy link
Copy Markdown
Member Author

@swift-ci test

Copy link
Copy Markdown
Contributor

@adrian-prantl adrian-prantl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the more generic representation in the transform block. Looks good to me!

@Snowy1803
Copy link
Copy Markdown
Member Author

Snowy1803 commented May 29, 2026

I have verified that on a program where PhiExpansion occurs on a debug value, the result is the same before the change (using fragments), and after the change (using a debug reconstruction block):

struct Pt {
    var x, y: Int
}

@inline(never)
func makeTrue(x: Int = 0) -> Bool {
    print(x)
    return true
}

func thing() {
    let pt: Pt
    if makeTrue() {
        pt = Pt(x: 4, y: 7)
    } else {
        pt = Pt(x: 2, y: 8)
    }
    let z = pt // break
    if makeTrue(x: z.x + 1) {
        print("yay")
    }
}

thing()

Compiled with optimisations, z.x has the correct value in both cases
Even if pt has the same value as z, it is not available at that location. Maybe it would be worth copying debug values across basic blocks (salvageStoreDebugInfo adds debug values for the assignments within the condition branches, but the debug_value is unknown after the condition)

@Snowy1803 Snowy1803 marked this pull request as ready for review May 29, 2026 10:57
@Snowy1803
Copy link
Copy Markdown
Member Author

The CI on the NFC pull request this one is based on is taking forever due to unrelated issues. This one passed CI, so I'll merge this one which will include the other one.

@Snowy1803 Snowy1803 merged commit c38bafc into swiftlang:main May 29, 2026
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants