Improve evaluation of nested ComposedFunctions

[martinholters]

• Add (the equivalent of) @assume_effects :terminates_globally to unwrap_composed. Although it could be inferred as Const, without the annotation, it was not elided for too complex inputs, resulting in unnecessary runtime overhead.
  EDIT: now effects: relax recursion detection for effects analysis #45993 is merged and this part isn't necessary.
• Reverse recursion order in call_composed. This prevents potentially changing argument types being piped through the recursion, making inference bail out. With the reversed order, only the tuple of remaining functions is changing during recursion and is becoming strictly simpler, letting inference succeed.

julia> f = reduce(∘, fill(sin,500));

julia> const g = reduce(∘, fill(sin,500));

julia> @time f(1.0)
  1.474751 seconds (1.83 M allocations: 120.273 MiB, 3.22% gc time, 99.00% compilation time) # master
  6.011575 seconds (4.02 M allocations: 278.036 MiB, 3.33% gc time, 100.00% compilation time) # PR
0.07698641344541407

julia> @btime f(1.0)
  14.102 ms (1000 allocations: 15.62 KiB) # master
  5.337 μs (1 allocation: 16 bytes) # PR
0.07698641344541407

julia> @btime g(1.0)
  14.091 ms (998 allocations: 15.59 KiB) # master
  1.878 ns (0 allocations: 0 bytes) # PR
0.07698641344541407

So increase in compilation time is noticeable, but execution is also much faster. (Yes, we can const-prop and completely elide g here). Also note that compilation time is still much better than with 1.8-rc1 (or 1.7), where it is several minutes.

That said, the fact that we have to replace the concise (c::ComposedFunction)(x...; kw...) = c.outer(c.inner(x...; kw...)) with the convoluted construction still makes me sad.

Fixes #45877.

[aviatesk]

You can test this improvement as like:

test/operators.jl

include("compiler/irutils.jl")
const issue_45877 = reduce(∘, fill(sin,500))
@test fully_eliminated() do
    issue_45877(1.0)
end

[martinholters]

@aviatesk can you explain why the @assume_effects is necessary? On master I find

julia> const g = reduce(∘, fill(sin,500));

julia> only(code_typed() do
           Base.unwrap_composed(g)
       end)[2]
NTuple{500, typeof(sin)}

julia> Base.infer_effects() do
           Base.unwrap_composed(g)
       end
(+c,+e,+n,!t,+s)

So inference succeeds which implies that it follows the recursion to the end, therefore obviously has figured out that there is an end. But the effects don't seem to catch that. Is there some way we could make the effects here more precise? If we could avoid the @assume_effects, there would also no longer be a need for the code movement.

[aviatesk]

While debugging #45781, I found that the root problem there was that :terminates effect seems to be tainted too aggressively by recursion and type information and effect information are not synced in terms of when they are cached or refined.

I think we are tainting the effect too aggressively here:

julia/base/compiler/abstractinterpretation.jl

Lines 619 to 622 in b11ccae

	elseif edgecycle
	# Some sort of recursion was detected. Even if we did not limit types,
	# we cannot guarantee that the call will terminate
	effects = Effects(effects; terminates=ALWAYS_FALSE)

since edgecycle basically means there are calls of same Method, but still their MethodInstances can be different.
We can sync them more if we taint the terminates effect by detecting recursion per MethodInstance basis. So basically we need to implement such analysis (maybe reusing a part of the similar type-level analysis for interprocedural recursion detection).

[aviatesk]

We can try to improve the recursion detection for effect analysis instead, but I'm also fine with merging this for now and tackle the improvement later.

[martinholters]

I don't mind either way. I won't have the bandwidth to look at improving effect analysis anytime soon, don't know whether you can tackle it in the foreseeable future. If no, we probably should merge as is. But I have no personal interest in deeply nested composed functions, so no hurry from my side.

[ianatol]

LGTM.

I think the @assume_effects is fine for the time being, while Shuhei looks into improving the recursion detection for effects.