This is interesting 
I’ve always had the (mis?) conception that using BigFloat in Tulip was going to be terribly slow, because that’s the way things are with BigFloat. If there were any compiler-related inefficiencies, I would have expected them to be negligible anyway.
As for JET: I have very little (virtually zero) experience with it, so I can’t really comment on why that line is flagged. I ran the code you shared (Julia1.7, Tulip@master), and JET also reported hundreds of issues/runtime dispatch that were mostly related to broadcast and the use of @printf
For instance, I saw a large number of such messages from JET:
││┌ @ broadcast.jl:516 Base.Broadcast.length(%157)
│││ runtime dispatch detected: Base.Broadcast.length(%157::Base.OneTo{Int64})
@nsajko: I you want to open an issue in Tulip.jl to track this, I will happily help the best I can.