inference: prioritize force_constant_prop over const_prop_entry_heuristic

[aviatesk]

Currently our constant-prop' heuristics work in the following way:

1. const_prop_entry_heuristic
2. const_prop_argument_heuristic & const_prop_rettype_heuristic
3. force_const_prop custom heuristic & !const_prop_function_heuristic
4. MethodInstance specialization and const_prop_methodinstance_heuristic

This PR changes it so that the step 1. now works like:

1. force_const_prop custom heuristic & const_prop_entry_heuristic

and the steps 2., 3. and 4. don't change

This change particularly allows us to more forcibly constant-propagate
for getproperty and setproperty!, and inline them more, e.g.:

# if we don't force constant-prop', `T = fieldtype(Foo, ::Symbol)` will be union-split to
# `Union{Type{Any},Type{Int}` and it will make `convert(T, nothing)` too costly
# and it leads to inlining failure
mutable struct Foo
    val
    _::Int
end

function setter(xs)
    for x in xs
        x.val = nothing # `setproperty!` can be inlined with this PR
    end
end

(motivated by @vchuravy's example at JuliaParallel/MPI.jl#492)

It might be useful because now we can intervene into the constant-prop'
heuristic in a more reliable way with the aggressive_constprop interface.

I did the simple benchmark below, and it looks like this change doesn't
cause the latency problem for this particular example:

~/julia master aviatesk@amdci2 6s
❯ ./usr/bin/julia -e '@time using Plots; @time plot(rand(10,3))'
  3.708500 seconds (7.28 M allocations: 506.128 MiB, 3.45% gc time, 1.13% compilation time)
  2.817794 seconds (3.45 M allocations: 195.127 MiB, 7.84% gc time, 53.76% compilation time)

~/julia avi/forceconstantprop aviatesk@amdci2 6s
❯ ./usr/bin/julia -e '@time using Plots; @time plot(rand(10,3))'
  3.622109 seconds (7.02 M allocations: 481.710 MiB, 4.19% gc time, 1.17% compilation time)
  2.863419 seconds (3.44 M allocations: 194.210 MiB, 8.02% gc time, 53.53% compilation time)

[vtjnash]

These seem a bit confusingly named. Of the "heuristic" functions, only const_prop_argument_heuristic implements heuristics for whether more analysis of the arguments are likely profitable, while the others implement checks for whether the result seems possible to improve.

[aviatesk]

So how about these renames ?

• const_prop_entry_heuristic -> const_prop_entry_check
• const_prop_argument_heuristic: unchanged
• const_prop_rettype_heuristic -> const_prop_rettype_check
• const_prop_function_heuristic: unchanged
• const_prop_methodinstance_heuristic: unchanged

To me const_prop_function_heuristic and const_prop_methodinstance_heuristic still seem to implement some heuristic logic rather than optimal analytic checks.

FWIW, JET seems to be the only consumer of those functions for now, and so I guess these renames won't be much painful at this moment: https://juliahub.com/ui/Search?type=code&q=const_prop&r=true

[vtjnash]

Ah, I missed those two also. I suppose from your example some might want to change these to add heuristics too? The main question in my mind was whether it made sense for 'force' to override them, since checks are somewhat different from heuristics.

[aviatesk]

yeah, currently force overwrites const_prop_entry_heuristic/const_prop_function_heuristic/!const_prop_methodinstance_heuristic, so I think it's more consistent if it overwrites the remaining two.

#41889 will generalize this interface and it will also generalize this force overwrite logic as well.