applicable requires a dynamic lookup, which means this implementation cannot be constant folded anymore, if I'm not mistaken:

julia> Base.infer_effects(prevpow, (Int, Int))
(+c,+e,!n,+t,+s,+m,+i)

julia> Base.infer_effects(prevpow_new, (Int, Int))
(!c,!e,!n,!t,!s,!m,+i)′

Note how the current version is consistent (+c), free of sideeffects (+e), always terminates (+t), doesn't access task local state (+s) and only uses memory inaccessible to other functions (+m). In contrast, the new version taints all these effects, making it non-constant foldable for all argument types. See ??Base.@assume_effects for more information on what these effects mean in detail.

I think it'll be better to write a specialized method for BigInt (or use the corresponding GMP function, if that exists) in base/gmp.jl if we want to support BigInt in these functions. Such a version would also have the advantage of being able to reuse intermediary memory of the various internal BigInt allocations, which this version can't do (and thus allocates a lot). The approach I'd take here is to have prevpow(x, y::BigInt) = prevpow(big(x), y) (and likewise for BigInt in the first argument position), and then implement _prevpow(x::BigInt, y::BigInt), using the fact that x is in our controlled allocation to mutate x in-place with the Base.GMP.MPZ API, and return that.

Oof, OK. I guess this means that digits! and invmod also need fixing. They use hastypemax, which uses applicable.

No, hastypemax works on the type, which is known for the important constant foldable cases - it compiles away for e.g. Int, which is specialized to just return true (check @edit Base.hastypemax(Int)). Since pretty much every operation with BigInt needs the runtime for allocations anyway, I guess that's why it's used there as a fallback? You could try to use that here as well, good catch.

Regardless, if performance for BigInt is the goal, an in-place method will likely be required.

Ping. The failures are system-dependent and surely unrelated.

@Seelengrab are your concerns resolved?

If BigInt performance is not a concern, yes, this version seems good. I'll maintain though that explicit BigInt support with promotion at the start & in-place operations would be better, but it's not blocking the PR.

If BigInt performance is not a concern, yes, this version seems good. I'll maintain though that explicit BigInt support with promotion at the start & in-place operations would be better, but it's not blocking the PR.

BigInt is a red herring here, this PR is a bugfix to (more or less) generic code, where BigInt just happens to be an example where the code is currently broken. A separate method for BigInt, as a performance optimization, is clearly completely off-topic here.

bump