propagate method metadata to keyword sorter methods

[JeffBezanson]

Arguably, if a method is declared @inline we should propagate that to all the methods we generate for it, including the keyword sorter. However, AFAICT #45028 still needs a @constprop declaration to function.

[aviatesk]

Do we want to generalize this to other :meta annotations?

• :aggressive_constprop/:no_constprop
• :propagate_inbounds
• maybe :pure and :purity also?

julia> lwr = Meta.lower(@__MODULE__, quote
           Base.@constprop :aggressive function foo(pos; kw)
               pos + kw
           end
       end);

julia> (lwr.args[1].code[16].args[3]::Core.CodeInfo).constprop
0x01

julia> (lwr.args[1].code[24].args[3]::Core.CodeInfo).constprop # kwsorter
0x00

---

AFAICT #45028 still needs a @constprop declaration to function.

Yes, I also found that @inline _cat(catdims, A::AbstractArray{T}...) where {T} = cat_t(T, A...; dims=catdims) isn't enough to enable constprop' since the body of cat_t without constant information is still too complex and it won't be jl_ir_flag_inlineable even with the extra inlineability cost (it contains 4 dynamic dispatches).

[timholy]

Do we want to generalize this to other :meta annotations?

Yes please (see #45050). The inability to block constprop on certain "derived" methods is a substantial contribution to latency in packages that have otherwise been carefully TTFX-optimized. I've even added workarounds in some cases, e.g., https://github.com/JuliaImages/ImageView.jl/blob/786fbf584b39387d2d3b5964e4cb40fcb4a3daf3/src/ImageView.jl#L743-L751

[aviatesk]

I rebased this PR and also added more supports for propagating other metadata to keyword sorter methods too.
I also added test cases and now all the cases reported in #45050 should be covered by this PR.

Although I'm sure this PR is working, I'd like to have a review from others especially on flisp code, since I'm not very familiar with the codebase.

[aviatesk]

@nanosoldier runbenchmarks("inference", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[JeffBezanson]

Should filter out expressions that end up empty, (meta).

[aviatesk]

(filter meta? prologue) should already filter out the empty (meta) case?

julia/src/ast.scm

Line 527 in a4e275b

(and (length> e 1) (eq? (car e) 'meta)))

[JeffBezanson]

For purity we can only keep the ones that are true of keyword sorters. Safer not to propagate them at all. But I think the following apply to keyword sorters:

• consistent
• effect_free
• terminates_globally
• notaskstate

But please check me on that!

[aviatesk]

I think keyword sorters are usually:

• :consistent
• :effect_free
• :terminates_locally (:terminates_globally requires that of the body function itself)
• :notaskstate

but they are not :nothrow (since they can throw any of TypeError/UndefKeywordError/MethodError).

Well, I'd argue it is okay to propagate the effects assumed by Base.@assume_effects to keyword sorters, since the point of using the macro to override the conclusion that is otherwise derived by the effect analysis.
If we write

Base.@assume_effects :total specific(A::Type, B::Type; v::Number=1) =
   v * one(ccall(:jl_type_morespecific, Cint, (Any, Any), A, B) ≠ 0 ? A : B)

then IMO we'd like to assume both specific(Int, Integer) and specific(Int, Integer; v=42) are :total (and therefore :nothrow also)?

[aviatesk]

@JeffBezanson Can I request your review on this again? I'd like to move this forward once CI runs green.