Ok, now I can reproduce it. It looks like @turbo is confused by a name with two module qualifiers, Base.FastMath.exp_fast.
julia> using Tullio, LoopVectorization
julia> let rt=rand(100)
a = @inbounds @fastmath @tullio et[n] := exp(rt[n]) avx=false
@show sum(a)
b = @inbounds @fastmath @tullio et[n] := exp(rt[n])
@show sum(b)
end;
sum(a) = 165.47486910574332
ERROR: UndefVarError: `exp_fast` not defined
Stacktrace:
[1] #239#ππΈπ!
@ ~/.julia/packages/Tullio/NGyNM/src/macro.jl:1093 [inlined]
Reproducer without @tullio:
julia> let rt = collect(1:0.1:10.0)
s = 0.0
for i in eachindex(rt)
s += exp(rt[i])
end
s
end
231435.5678161179
julia> let rt = collect(1:0.1:10.0)
s = 0.0
@turbo for i in eachindex(rt)
s += exp(rt[i])
end
s
end
231435.56781611795
julia> let rt = collect(1:0.1:10.0)
s = 0.0
@turbo for i in eachindex(rt)
s += Base.FastMath.exp_fast(rt[i])
end
s
end
ERROR: UndefVarError: `exp_fast` not defined
Stacktrace:
[1] top-level scope
@ ./REPL[44]:3
julia> let rt = collect(1:0.1:10.0), e_f = Base.FastMath.exp_fast
s = 0.0
@turbo for i in eachindex(rt)
s += e_f(rt[i])
end
s
end
231435.56781611795
While this is a bug, I stress that @fastmath @tullio is not a good idea. You can turn the mode on or off with a keyword, but letting the @fastmath macro change things is liable to cause problems (e.g. here it defeats the calculation of gradients).
I suspect that @fastmath @turbo is also uniformly a bad idea, since that macro also replaces many functions it knows about with faster ones.