LLVM bug encountered in Turing.jl #658
Comments
|
Perhaps this is it? (from https://pipelines.actions.githubusercontent.com/serviceHosts/0c878943-700a-40ba-8133-274020e1bd9e/_apis/pipelines/1/runs/18942/signedlogcontent/3?urlExpires=2023-03-09T15%3A20%3A38.4878704Z&urlSigningMethod=HMACV1&urlSignature=zszbo6Vi8C%2F6qgCvcPnLd7zFxgY7qaKJW267uuCKCxs%3D https://github.com/TuringLang/Turing.jl/actions/runs/4352542010/jobs/7605450766 ) Humorously, it is a bug in not handling a memmove of 0 bytes. Should get a patch for this quickly. |
|
Fix for the memmove error at least, if that happens to be the same: EnzymeAD/Enzyme#1016 |
|
This does not reproduce on main, instead revealing a Turing type unstable getfield. Please reopen if this persists. |
|
With main, I get a different error message: julia> LogDensityProblems.logdensity_and_gradient(f, [0.0, 1.0, 1.0])
ERROR: Return of nothing must be marked Const
Stacktrace:
[1] error(s::String)
@ Base ./error.jl:35
[2] #s451#163
@ ~/.julia/packages/Enzyme/SUstD/src/compiler.jl:8173 [inlined]
[3] var"#s451#163"(F::Any, Fn::Any, DF::Any, A::Any, TT::Any, Mode::Any, ModifiedBetween::Any, width::Any, specid::Any, ReturnPrimal::Any, ShadowInit::Any, ::Any, #unused#::Type, f::Any, df::Any, #unused#::Type, tt::Any, #unused#::Type, #unused#::Type, #unused#::Type, #unused#::Type, #unused#::Type, #unused#::Any)
@ Enzyme.Compiler ./none:0
[4] (::Core.GeneratedFunctionStub)(::Any, ::Vararg{Any})
@ Core ./boot.jl:582
[5] thunk
@ ~/.julia/packages/Enzyme/SUstD/src/compiler.jl:8218 [inlined]
[6] thunk
@ ~/.julia/packages/Enzyme/SUstD/src/compiler.jl:8211 [inlined]
[7] runtime_generic_augfwd(activity::Val{(false, false, true)}, width::Val{1}, ModifiedBetween::Val{(true, true, true)}, RT::Val{NamedTuple{(Symbol("1"), Symbol("2"), Symbol("3")), Tuple{Any, Any, Any}}}, f::typeof(Base.depwarn), df::Nothing, primal_1::String, shadow_1_1::Nothing, primal_2::Symbol, shadow_2_1::Symbol)
@ Enzyme.Compiler ~/.julia/packages/Enzyme/SUstD/src/compiler.jl:1050Regardless, the problem here is not Turing but it seems the issues are caused by the line y ~ MvNormal(μ, σ)in the model, or rather the fact that this y ~ MvNormal(μ, σ^2 * I)(which the deprecated call is forwarded to), fixes the example: julia> LogDensityProblems.logdensity_and_gradient(f, [0.0, 1.0, 1.0])
(-130.65686521906758, [-6.769465686621555, -3.431034957759231, 226.65365479589548])@wsmoses should Enzyme be able to handle the deprecation? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
@yebai mentioned to me: It is difficult to figure out which function caused Enzyme to fail below. This makes it hard to find out which function needs a chain rule.
@yebai Can you provide a stacktrace. @wsmoses said on slack that this is an LLVM bug.
The text was updated successfully, but these errors were encountered: