Description
Previous ID | SR-15849 |
Radar | None |
Original Reporter | @BradLarson |
Type | Bug |
Attachment: Download
Additional Detail from JIRA
Votes | 2 |
Component/s | Compiler |
Labels | Bug, AutoDiff |
Assignee | None |
Priority | Medium |
md5: 82c8ff1d6e5a28a6187d0ca10fe66599
Issue Description:
Certain differentiable mutating functions on a struct that contain control flow within their bodies can lead to an assertion failure of `SIL verification failed: conflicting debug variable type!: DebugVars[argNum].second == DebugVarTy`. This appears to only happen in optimized builds where debug symbols are enabled.
It has been difficult to isolate a reproducer for this. The closest public reproducing case is in this pull request when building the BatchNorm struct. The representative failure output seen there is in the attached file.
SIL verification failed: conflicting debug variable type!: DebugVars[argNum].second == DebugVarTy
Verifying instruction:
%35 = apply %15<τ_0_0>(%14) : $@convention(method) <τ_0_0 where τ_0_0 : TensorFlowFloatingPoint> (@thin BatchNorm<τ_0_0>.TangentVector.Type) -> @owned BatchNorm<τ_0_0>.TangentVector // users: %36, %310, %312
-> debug_value %35 : $BatchNorm<τ_0_0>.TangentVector, let, name "self", argno 2, implicit, expr op_deref // id: %36
In function:
// pullback of BatchNorm.callAsFunction(_:)
[See file for more]
1. Swift version 5.6-dev (LLVM 4c76989fa680f44, Swift 8f443ffbd430133)
2. Compiling with the current language version
3. While verifying SIL function "@$s10TensorFlow9BatchNormV14callAsFunctionyAA0A0VyxGAGFAA0aB13FloatingPointRzlTJpUSpSr".
for 'callAsFunction(_:)' (at /home/fan/Projects/PL/Swift/s4tf_2021/swift-apis/Sources/TensorFlow/Layers/Normalization.swift:102:10)
#​0 0x000055b3e1279f33 llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/usr/lib/swift-git/bin/swift-frontend+0x651df33)
#​1 0x000055b3e1277c5e llvm::sys::RunSignalHandlers() (/usr/lib/swift-git/bin/swift-frontend+0x651bc5e)
#​2 0x000055b3e127a2ba SignalHandler(int) (/usr/lib/swift-git/bin/swift-frontend+0x651e2ba)
#​3 0x00007f2dcc6c1870 __restore_rt (/usr/lib/libpthread.so.0+0x13870)
#​4 0x00007f2dcc10dd22 raise (/usr/lib/libc.so.6+0x3cd22)
#​5 0x00007f2dcc0f7862 abort (/usr/lib/libc.so.6+0x26862)
#​6 0x000055b3dbd6a2e2 (/usr/lib/swift-git/bin/swift-frontend+0x100e2e2)
#​7 0x000055b3dbd88d48 (anonymous namespace)::SILVerifier::visitSILInstruction(swift::SILInstruction*) (/usr/lib/swift-git/bin/swift-frontend+0x102cd48)
#​8 0x000055b3dbd6c1c5 (anonymous namespace)::SILVerifier::visitSILBasicBlock(swift::SILBasicBlock*) (/usr/lib/swift-git/bin/swift-frontend+0x10101c5)
#​9 0x000055b3dbd652ce swift::SILFunction::verify(bool) const (/usr/lib/swift-git/bin/swift-frontend+0x10092ce)
#​10 0x000055b3dbd6926b swift::SILModule::verify() const (/usr/lib/swift-git/bin/swift-frontend+0x100d26b)
#​11 0x000055b3dbc9c1d6 swift::CompilerInstance::performSILProcessing(swift::SILModule*) (/usr/lib/swift-git/bin/swift-frontend+0xf401d6)
#​12 0x000055b3dbaa864a performCompileStepsPostSILGen(swift::CompilerInstance&, std::unique_ptr<swift::SILModule, std::default_delete<swift::SILModule> >, llvm::PointerUnion<swift::ModuleDecl*, swift::SourceFile*>, swift::PrimarySpecificPaths const&, int&, swift::FrontendObserver*) (/usr/lib/swift-git/bin/swift-frontend+0xd4c64a)
#​13 0x000055b3dbaa8022 performCompileStepsPostSema(swift::CompilerInstance&, int&, swift::FrontendObserver*) (/usr/lib/swift-git/bin/swift-frontend+0xd4c022)
#​14 0x000055b3dba9bb64 swift::performFrontend(llvm::ArrayRef<char const*>, char const*, void*, swift::FrontendObserver*) (/usr/lib/swift-git/bin/swift-frontend+0xd3fb64)
#​15 0x000055b3dba67c3b swift::mainEntry(int, char const**) (/usr/lib/swift-git/bin/swift-frontend+0xd0bc3b)
#​16 0x00007f2dcc0f8b25 __libc_start_main (/usr/lib/libc.so.6+0x27b25)
#​17 0x000055b3dba6782e _start (/usr/lib/swift-git/bin/swift-frontend+0xd0b82e)
This regression appeared some time in September 2021, and I need to isolate this further. I also need to minimize a better reproducer case. I'm creating this issue to provide a point of coordination as we work to narrow this down.