[AutoDiff] Specifically-shaped differentiable functions yield "conflicting debug info for argument" assertion failure #58660
Assignees
Comments
BradLarson
added
bug
|
So, here it looks like line number information was lost somehow. Weird :) |
|
I narrowed down the reproducer much further. On older toolchains, it still triggers the old debug info crash that was affecting PassiveLogic and S4TF. The crash's signature changed some time between the 2022-04-04 and 2022-04-24 toolchains, based on what I tested. import _Differentiation
// May be a `struct` or `class`.
class MyState: Differentiable {
// All of these must be stored instance properties. There must be at least 7
// differentiable properties of any type.
var property1: Float = 0
var property2: Float = 0
var property3: Float = 0
var property4: Float = 0
var property5: Float = 0
var property6: Float = 0
var property7: Float = 0
}
struct MyModel: Differentiable {
// May be `var` or `let`, but must not be `@noDerivative`. Must be a stored
// instance property.
let property1 = MyState()
// Must be an instance property, either stored or computed.
var property2: Float {
// `get` must exist, and may add `mutating` attribute.
get { 0 }
// Cannot add `nonmutating` attribute to `set`.
set { }
}
// Must be an instance member. May be a function or computed property, but not
// a stored property.
var member3: Float {
// May not add `mutating` attribute.
get { 0 }
}
@differentiable(reverse)
mutating func member4() {
// Must be a differentiable type.
var localVar: Float = 0
// Must be assigned from the value of `localVar`, not the value of anything else.
property2 = localVar
// `false` may instead be any expression that returns a `Bool`.
if false {
localVar = member3
}
}
}Terminal output: |
|
This seems to be quite a weird combination of inlining, SIL mem2reg and autodiff that was required to trigger an assertion. Surprisingly enough, fixing one particular TODO resolved the issue |
asl
added a commit
to asl/swift
that referenced
this issue
May 11, 2022
`salvageDebugInfo` is called during SIL Mem2Reg and could produce misleading debug info in the following case: ``` %a = alloc_stack $MyModel.TangentVector, var, name "self", argno 1, implicit, loc "debug2.swift":37:17 ... ... store %b to %a : $*MyModel.TangentVector ``` Such SIL could be created as a result of inlining (where store comes from the inlined function). Before this patch we'd end with `debug_value` instruction with variable information, but without or incorrect location. This caused LLVM IR debug info verifier assertions when there might be another instruction with complete debug info (including location) for the same argument. After this patch we always reuse it from destination alloca Fixes swiftlang#58660
asl
added a commit
that referenced
this issue
May 11, 2022
…58763) `salvageDebugInfo` is called during SIL Mem2Reg and could produce misleading debug info in the following case: ``` %a = alloc_stack $MyModel.TangentVector, var, name "self", argno 1, implicit, loc "debug2.swift":37:17 ... ... store %b to %a : $*MyModel.TangentVector ``` Such SIL could be created as a result of inlining (where store comes from the inlined function). Before this patch we'd end with `debug_value` instruction with variable information, but without or incorrect location. This caused LLVM IR debug info verifier assertions when there might be another instruction with complete debug info (including location) for the same argument. After this patch we always reuse it from destination alloca Fixes #58660
drexin
pushed a commit
to drexin/swift
that referenced
this issue
Jun 3, 2022
…wiftlang#58763) `salvageDebugInfo` is called during SIL Mem2Reg and could produce misleading debug info in the following case: ``` %a = alloc_stack $MyModel.TangentVector, var, name "self", argno 1, implicit, loc "debug2.swift":37:17 ... ... store %b to %a : $*MyModel.TangentVector ``` Such SIL could be created as a result of inlining (where store comes from the inlined function). Before this patch we'd end with `debug_value` instruction with variable information, but without or incorrect location. This caused LLVM IR debug info verifier assertions when there might be another instruction with complete debug info (including location) for the same argument. After this patch we always reuse it from destination alloca Fixes swiftlang#58660
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
Specifically-shaped differentiable functions can lead to an assertion failure of "conflicting debug info for argument" in optimized builds with debug symbols enabled. This has been an issue for some more complex differentiable Swift code top-of-tree Swift since at least September of 2021, but only recently have we been able to reproduce this in a single file.
To Reproduce
The following single-file reproducer will exhibit this behavior on the 2022-04-23 nightly toolchain snapshot or newer (PR #42245 needs to be in place for this to not hit an earlier assertion failure):
To reproduce, place the above in a file and run
swiftc -O -g file.swift. Note the need for both optimization and debug symbol generation.Expected behavior
Code compiles cleanly.
Results
The following is output:
Environment (please complete the following information):
The text was updated successfully, but these errors were encountered: