Improve inference in typejoin

[timholy]

This fixes hundreds of promote_rule invalidations from Unitful. Discovered in a conversation with @louisponet

@aviatesk, inference of typejoin in one case shows an interesting phenomenon:

descend(typejoin, (Type{Int}, Any); optimize=false, iswarn=true)

reveals that inference fails to discover that a.name returns a TypeName and a.parameters returns a SimpleVector. AFAICT the Const annotation interferes with knowing that a behaves as a DataType. Is this easily fixable or should I add some annotations?

[aviatesk]

Reduced a bit further:

julia> code_typed((Type{Int},); optimize=false) do x
           x = x::DataType
           while x <: Number
               x = supertype(x)::DataType
           end
           x.name
       end
1-element Vector{Any}:
 CodeInfo(
1 ─      (x@_3 = x@_2)::Core.Const(Int64)
└──      (x@_3 = Core.typeassert(x@_3::Core.Const(Int64), Main.DataType))::Core.Const(Int64)
2 ┄ %3 = (x@_3 <: Main.Number)::Bool
└──      goto #4 if not %3
3 ─ %5 = Main.supertype(x@_3)::Any
│        (x@_3 = Core.typeassert(%5, Main.DataType))::DataType
└──      goto #2
4 ─ %8 = Base.getproperty(x@_3, :name)::Any
└──      return %8
) => Any

[aviatesk]

Okay, so I figured out one of the problems here is that supertype(T) can produce constant information when T is a precise Type object and so inference on

while [...]
    x = supertype(x)
end

requires data flow iterations until the type of x gets converged.
And when we try to converge x here, we will end up with a looser type when the initial type of x is precise (e.g. x::Const(Int)):

julia> CC.tmerge(
           Union{Type{Int},Type{Integer},Type{Signed}},
           Union{Type{Integer},Type{Signed},Type{Real}}
           )
Type

Still I'm not sure why (x@_3 = Core.typeassert(%5, Main.DataType))::DataType doesn't "recover" x@_3::DataType information.

---

So the following uses of inferencebarrier improves the inference of typejoin (and it also cuts off the need for data flow iteration explained above):

diff --git a/base/promotion.jl b/base/promotion.jl
index 845e16ca499..4355a9d3364 100644
--- a/base/promotion.jl
+++ b/base/promotion.jl
@@ -77,7 +77,7 @@ function typejoin(@nospecialize(a), @nospecialize(b))
     elseif b <: Tuple
         return Any
     end
-    a, b = a::DataType, b::DataType
+    a, b = inferencebarrier(a)::DataType, inferencebarrier(b)::DataType
     while b !== Any
         if a <: b.name.wrapper
             while a.name !== b.name

---

Maybe we want to file this problem in a separate issue?
/cc @vtjnash @martinholters

[timholy]

Maybe we want to file this problem in a separate issue?

Sure, do you want to open it? You've clearly taken it farther than me.

Should I add the inferencebarrier to this PR, or would you rather leave that out pending possible changes to inference? Update: I went ahead and added it here.

[aviatesk]

Sure, do you want to open it?

Done: #44425

Should I add the inferencebarrier to this PR

yep, the apparent allocation with inferencebarrier should be removed by our SROA pass, and so that change won't incur any runtime performance problem.

[Keno]

julia> CC.tmerge(
           Union{Type{Int},Type{Integer},Type{Signed}},
           Union{Type{Integer},Type{Signed},Type{Real}}
           )

Seems like tmerge could give DataType here.

[timholy]

Rats, I should have tagged this for backporting a long time ago. Fixes about 1800 invalidations from loading Makie. CC @SimonDanisch.

[aviatesk]

Backported.