-
Notifications
You must be signed in to change notification settings - Fork 10.5k
[AutoDiff] Conflicting debug info for argument with custom valueWithPullback #62608
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
cc @asl |
The offending function is define internal swiftcc void @"$s6custom19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU_TJpSUpSr"(%TSd* nocapture dereferenceable(8) %0, %swift.refcounted* %1) #0 !dbg !836 {
%3 = alloca %TSd, align 8
call void @llvm.dbg.declare(metadata %TSd* %3, metadata !840, metadata !DIExpression()), !dbg !847
%4 = bitcast %TSd* %3 to i8*, !dbg !848
call void @llvm.lifetime.start.p0i8(i64 8, i8* %4), !dbg !848
%5 = getelementptr inbounds %TSd, %TSd* %3, i32 0, i32 0, !dbg !848
store double 0.000000e+00, double* %5, align 8, !dbg !848
%6 = call swiftcc i8* @swift_autoDiffProjectTopLevelSubcontext(%swift.refcounted* %1) #8, !dbg !850
%7 = bitcast i8* %6 to %"T6custom061_AD__$s6custom19testUpdateByCallingyyKF8fOfArrayL_5arraySdSayK33G_tFySdzcfU__bb4__PB__src_0_wrt_033_E323A9EF754FCEC1F4377C8DDDEDCDFBLLV"*, !dbg !850
%8 = getelementptr inbounds %"T6custom061_AD__$s6custom19testUpdateByCallingyyKF8fOfArrayL_5arraySdSayK33G_tFySdzcfU__bb4__PB__src_0_wrt_033_E323A9EF754FCEC1F4377C8DDDEDCDFBLLV", %"T6custom061_AD__$s6custom19te
%9 = bitcast %"T6custom061_AD__$s6custom19testUpdateByCallingyyKF8fOfArrayL_5arraySdSayK35G_tFySdzcfU__bb4__Pred__src_0_wrt_033_E323A9EF754FCEC1F4377C8DDDEDCDFBLLO"* %8 to %"T6custom061_AD__$s6custom19testUpdat
%10 = getelementptr inbounds %"T6custom061_AD__$s6custom19testUpdateByCallingyyKF8fOfArrayL_5arraySdSayK33G_tFySdzcfU__bb2__PB__src_0_wrt_033_E323A9EF754FCEC1F4377C8DDDEDCDFBLLV", %"T6custom061_AD__$s6custom19t
%11 = bitcast %"T6custom061_AD__$s6custom19testUpdateByCallingyyKF8fOfArrayL_5arraySdSayK35G_tFySdzcfU__bb2__Pred__src_0_wrt_033_E323A9EF754FCEC1F4377C8DDDEDCDFBLLO"* %10 to i8**, !dbg !850
%12 = load i8*, i8** %11, align 8, !dbg !850
%13 = getelementptr inbounds %TSd, %TSd* %0, i32 0, i32 0, !dbg !850
%14 = load double, double* %13, align 8, !dbg !850
call void @llvm.dbg.value(metadata double %14, metadata !841, metadata !DIExpression()), !dbg !851
... So, |
Ok, I think we're having some generic issue about debug info generation in differential swift code (and it looks similar to #55703 actually). This is generated pullback: // pullback of closure #1 in fOfArray #1 (array:) in testUpdateByCalling()
sil private [ossa] @$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU_TJpSUpSr : $@convention(thin) (@inout Double, @guaranteed Builtin.NativeObject) -> () {
// %0 // users: %100, %23, %22
// %1 // user: %18
bb0(%0 : $*Double, %1 : @guaranteed $Builtin.NativeObject):
%2 = alloc_stack $Double, var, name "element", argno 1, loc "custom.swift":52:47, scope 2 // users: %107, %100, %97, %56, %55, %5
%3 = witness_method $Double, #AdditiveArithmetic.zero!getter : <Self where Self : AdditiveArithmetic> (Self.Type) -> () -> Self : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveAr
%4 = metatype $@thick Double.Type, loc "custom.swift":52:47, scope 2 // user: %5
%5 = apply %3<Double>(%2, %4) : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveArithmetic> (@thick τ_0_0.Type) -> @out τ_0_0, loc "custom.swift":52:47, scope 2
%6 = alloc_stack $Double, var, name "element", argno 1, loc "custom.swift":52:47, scope 2 // users: %106, %105, %84, %83, %67, %54, %52, %51, %9
%7 = witness_method $Double, #AdditiveArithmetic.zero!getter : <Self where Self : AdditiveArithmetic> (Self.Type) -> () -> Self : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveAr
%8 = metatype $@thick Double.Type, loc "custom.swift":52:47, scope 2 // user: %9
%9 = apply %7<Double>(%6, %8) : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveArithmetic> (@thick τ_0_0.Type) -> @out τ_0_0, loc "custom.swift":52:47, scope 2
%10 = alloc_stack $Double, var, name "element", argno 1, loc "custom.swift":52:47, scope 2 // users: %104, %103, %84, %83, %56, %55, %54, %52, %51, %37, %36, %13
%11 = witness_method $Double, #AdditiveArithmetic.zero!getter : <Self where Self : AdditiveArithmetic> (Self.Type) -> () -> Self : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveA
%12 = metatype $@thick Double.Type, loc "custom.swift":52:47, scope 2 // user: %13
%13 = apply %11<Double>(%10, %12) : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveArithmetic> (@thick τ_0_0.Type) -> @out τ_0_0, loc "custom.swift":52:47, scope 2
%14 = alloc_stack $Double, var, name "element", argno 1, loc "custom.swift":52:47, scope 2 // users: %102, %101, %37, %36, %23, %22, %17
%15 = witness_method $Double, #AdditiveArithmetic.zero!getter : <Self where Self : AdditiveArithmetic> (Self.Type) -> () -> Self : $@convention(witness_method: AdditiveArithmetic) <τ_0_0 where τ_0_0 : AdditiveA
%16 = metatype $@thick Double.Type, loc "custom.swift":52:47, scope 2 // user: %17 Note that we're having multiple locations for After SROA some of these alloca's got sliced: %2 = alloc_stack $Builtin.FPIEEE64, var, (name "element", loc "custom.swift":52:47, scope 2), argno 1, type $*Double, expr op_fragment:#Double._value, loc "<compiler-generated>":0:0, scope 2 // users: %110, %10
%3 = integer_literal $Builtin.Int64, 0, loc "custom.swift":52:47, scope 2 // user: %4
%4 = builtin "sitofp_Int64_FPIEEE64"(%3 : $Builtin.Int64) : $Builtin.FPIEEE64, loc "custom.swift":52:47, scope 2 // user: %5
%5 = struct $Double (%4 : $Builtin.FPIEEE64), loc "custom.swift":52:47, scope 2 // user: %6
%6 = destructure_struct %5 : $Double, loc "custom.swift":52:47, scope 2 // user: %7
store %6 to [trivial] %2 : $*Builtin.FPIEEE64, loc "custom.swift":52:47, scope 2 // id: %7
%8 = alloc_stack $Double, var, name "element", argno 1, loc "custom.swift":52:47, scope 2 // users: %90, %67, %63, %60, %93, %12, %109, %84
%9 = integer_literal $Builtin.Int64, 0, loc "custom.swift":52:47, scope 2 // user: %10
%10 = builtin "sitofp_Int64_FPIEEE64"(%9 : $Builtin.Int64) : $Builtin.FPIEEE64, loc "custom.swift":52:47, scope 2 // user: %11
%11 = struct $Double (%10 : $Builtin.FPIEEE64), loc "custom.swift":52:47, scope 2 // user: %12
store %11 to [trivial] %8 : $*Double, loc "custom.swift":52:47, scope 2 // id: %12
%13 = alloc_stack $Builtin.FPIEEE64, var, (name "element", loc "custom.swift":52:47, scope 2), argno 1, type $*Double, expr op_fragment:#Double._value, loc "<compiler-generated>":0:0, scope 2 // users: %108, %1
%14 = integer_literal $Builtin.Int64, 0, loc "custom.swift":52:47, scope 2 // user: %15
%15 = builtin "sitofp_Int64_FPIEEE64"(%14 : $Builtin.Int64) : $Builtin.FPIEEE64, loc "custom.swift":52:47, scope 2 // user: %16
%16 = struct $Double (%15 : $Builtin.FPIEEE64), loc "custom.swift":52:47, scope 2 // user: %17
%17 = destructure_struct %16 : $Double, loc "custom.swift":52:47, scope 2 // user: %18
store %17 to [trivial] %13 : $*Builtin.FPIEEE64, loc "custom.swift":52:47, scope 2 // id: %18
%19 = alloc_stack $Builtin.FPIEEE64, var, (name "element", loc "custom.swift":52:47, scope 2), argno 1, type $*Double, expr op_fragment:#Double._value, loc "<compiler-generated>":0:0, scope 2 // users: %107, %2
... Note that sliced allocas got artificial location information. After some optimizations we're ending with: %2 = alloc_stack $Double, var, name "element", argno 1, loc "custom.swift":52:47, scope 2 // users: %40, %26, %6, %54, %36
%3 = integer_literal $Builtin.Int64, 0, loc "custom.swift":52:47, scope 2 // user: %4
%4 = builtin "sitofp_Int64_FPIEEE64"(%3 : $Builtin.Int64) : $Builtin.FPIEEE64, loc "custom.swift":52:47, scope 2 // users: %21, %16, %5
%5 = struct $Double (%4 : $Builtin.FPIEEE64), loc "custom.swift":52:47, scope 2 // user: %6
store %5 to %2 : $*Double, loc "custom.swift":52:47, scope 2 // id: %6
%7 = builtin "autoDiffProjectTopLevelSubcontext"(%1 : $Builtin.NativeObject) : $Builtin.RawPointer, loc "custom.swift":52:44, scope 2 // user: %8
%8 = pointer_to_address %7 : $Builtin.RawPointer to [strict] $*_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb4__PB__src_0_wrt_0, loc "custom.swift":52:44, scope 2 // user: %9
%9 = struct_element_addr %8 : $*_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb4__PB__src_0_wrt_0, #_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb4__PB
%10 = load %9 : $*_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb4__Pred__src_0_wrt_0, loc "custom.swift":52:44, scope 2 // user: %13
%11 = struct_element_addr %0 : $*Double, #Double._value, loc "custom.swift":52:44, scope 2 // user: %12
%12 = load %11 : $*Builtin.FPIEEE64, loc "custom.swift":52:44, scope 2 // users: %15, %21
%13 = unchecked_enum_data %10 : $_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb4__Pred__src_0_wrt_0, #_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb4_
%14 = struct_extract %13 : $_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb2__PB__src_0_wrt_0, #_AD__$s4main19testUpdateByCallingyyKF8fOfArrayL_5arraySdSaySdG_tFySdzcfU__bb2__PB__sr
debug_value %12 : $Builtin.FPIEEE64, var, (name "element", loc "custom.swift":52:47, scope 2), argno 1, type $*Double, expr op_fragment:#Double._value, loc "<compiler-generated>":0:0, scope 2 // id: %15
... So, what happens is that we're having different debug info for argument number
@BradLarson @dan-zheng @rxwei Thoughts? |
Description
A specific configuration of a wrapper function around
valueWithPullback()
built with both optimization and debug symbol generation leads to an assertion failure ofconflicting debug info for argument
.Steps to reproduce
Place the following in a file:
And build it via
swiftc -O -g file.swift
. Note that both optimization and debug symbol generation must be used for this assertion failure to happen.The assertion failure looks something like the following:
Expected behavior
The file should build cleanly.
Environment
The text was updated successfully, but these errors were encountered: