You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a follow-up on #1608. The issue described there is about recent changes to the activity analysis that introduce incorrect derivative results in very specific input programs.
I'm providing a small (100 lines) reproducible example that demonstrates the difference in the before/after behaviour of the referenced changes:
LLVM IR
; ModuleID = 'LLVMDialectModule'
source_filename = "LLVMDialectModule"@enzyme_dupnoneed = linkonceconstanti80@enzyme_const = linkonceconstanti80@.str = privateunnamed_addrconstant [3 x i8] c"%f\00"declarei32@printf(ptr, ...)
declarevoid@__enzyme_autodiff0(...)
declarevoid@free(ptr)
declareptr@malloc(i64)
definei32@main() {
; prep arguments & shadows%input = callptr@malloc(i6464)
storedouble0.2, ptr%input%in_shadow = callptr@malloc(i648)
storei640, ptr%in_shadow%output = callptr@malloc(i648)
%out_shadow = callptr@malloc(i648)
storedouble1.000000e+00, ptr%out_shadow; autodiff callcallvoid (...) @__enzyme_autodiff0(ptr@f.preprocess, ptr%input, ptr%in_shadow, i641, ptr%output, ptr%out_shadow)
; print result%grad = loaddouble, ptr%in_shadowcalli32 (ptr, ...) @printf(ptr@.str, double%grad)
callvoid@free(ptr%input)
callvoid@free(ptr%in_shadow)
callvoid@free(ptr%output)
callvoid@free(ptr%out_shadow)
reti320
}
; This function just returns 2*input, its derivate should be 2.0.definevoid@f.preprocess(ptr%0, i64%1, ptr%2) {
; arithmetic block, changing anything here makes the bug go away%buffer1 = callptr@malloc(i64%1)
%tmp = callptr@malloc(i6472)
%4 = ptrtointptr%tmptoi64%5 = andi64%4, -64%6 = inttoptri64%5toptr%7 = loaddouble, ptr%0%8 = fmuldouble%7, 4.000000e+00storedouble%8, ptr%6callvoid@free(ptr%tmp)
storedouble%8, ptr%buffer1; prep arg 0 by setting the aligned pointer to the input%arg0 = alloca { ptr, ptr, i64 }
%arg0_aligned = getelementptrinbounds { ptr, ptr, i64 }, ptr%arg0, i640, i321storeptr%0, ptr%arg0_aligned; prep arg 1 by setting the aligned pointer to buffer1%arg1 = alloca { ptr, ptr, i64, [1 x i64], [1 x i64] }
%arg1_aligned = getelementptrinbounds { ptr, ptr, i64, [1 x i64], [1 x i64] }, ptr%arg1, i640, i321storeptr%buffer1, ptr%arg1_aligned; prep arg 2 by setting the aligned pointer to buffer2%arg2 = alloca { ptr, ptr, i64 }
%arg2_aligned = getelementptrinbounds { ptr, ptr, i64 }, ptr%arg2, i640, i321%buffer2 = callptr@malloc(i648)
storeptr%buffer2, ptr%arg2_aligned; nested call, required for bugcallvoid@nested(ptr%arg0, ptr%arg1, ptr%arg2)
; return a result from this function, needs to be positioned after arithmetic block for bug%x = loaddouble, ptr%0%y = fmuldouble%x, 2.0storedouble%y, ptr%2retvoid
}
; Identity function, 2nd argument required for bugdefinevoid@nested(ptr%0, ptr%1, ptr%2) {
; load aligned pointer from %0 & load argument value%4 = load { ptr, ptr, i64 }, ptr%0%5 = extractvalue { ptr, ptr, i64 } %4, 1%6 = loaddouble, ptr%5; load aligned pointer from %2 & store result value%7 = load { ptr, ptr, i64 }, ptr%2%8 = extractvalue { ptr, ptr, i64 } %7, 1storedouble%6, ptr%8retvoid
}
The example can be compiled and run with the following commands:
Oh fantastic. can you add this test to the PR and let's get it merged.
I do think that the solution we'll want to do is actually in visitStore rather than activity analysis, but doing that change should be conservatively suficient in the interim and we can have this test in place to ensure that any fix doesn't inadvertantly revert this behavior
Issue description
This is a follow-up on #1608. The issue described there is about recent changes to the activity analysis that introduce incorrect derivative results in very specific input programs.
I'm providing a small (100 lines) reproducible example that demonstrates the difference in the before/after behaviour of the referenced changes:
LLVM IR
The example can be compiled and run with the following commands:
Expected behaviour
The program prints
2.0
.Actual behaviour
The program prints
5.2
.Additional information
Reverting the changes in #1558, even just this single line, produces the expect behaviour:
Enzyme/enzyme/Enzyme/ActivityAnalysis.cpp
Line 2044 in ac391ac
The text was updated successfully, but these errors were encountered: