de-duplicate union type splitting inference for duplicate loads of immutable fields

[jakobnissen]

Edit 2023-03-17: Reduced example

julia> struct Foo
           x::Union{Int, Nothing}
       end

julia> function foo(x::Foo)
           x.x === nothing ? x.x : x.x + 1
       end;

julia> @code_native foo(Foo(1))

Here is a small working example:

using ErrorTypes # version 0.3

@inline f(x::Int)::Option{Int} = iszero(x) ? none : some(x + 1)
@inline g(x)::Option{Int} = some(@? f(x))
@inline h(x) = unwrap_or(g(x), 1)

Now check g(1):

• @code_warntype shows some type instability here, e.g. the final some appears to be able to be an Option{Nothing}, which would throw an error on the typeassert
• @code_native shows no error-throwing code, so it conflicts with @code_warntype.

Another issue which may or may not be related: Check @code_native h(1). It compiles to a single leaq instruction as expected. However, when putting it in a loop:

function foo(x)
    y = 0
    for i in x
        y += h(i)
    end
    y
end

it does not vectorize, even though this should be very easy to vectorize.

[jakobnissen]

Okay, I have finally reduced the problem:

using ErrorTypes
f(x) = iszero(x) ? none(Int) : some(x)

function good(x)
    y = f(x)
    data = y.data
    data isa Ok ? some(data._1) : convert(Option{Int}, Err(data._1))
end

function bad(x)
    y = f(x)
    y.data isa Ok ? some(y.data._1) : convert(Option{Int}, Err(y.data._1))
end

Two issues:

• In bad, despite checking that y.data isa Ok, this information is not given to the compiler.
• Even though the compiler has no inferred what the type of y.data._1 in the latter branch is (and that an error is impossible), @code_native does not show any code related to throwing an error.

[vtjnash]

Yes, we don't forward information from duplicate loads. This is one of several reasons we typically try to recommend using the native sum type Union{Some{T}, Exception} instead of building with a typed-error struct such an ExceptionOr{T}

[jakobnissen]

Just to be sure - does this also explain the fact that @code_native and @code_warntype disagree about what is actually inferred at a given point in time?

[JeffBezanson]

@code_warntype runs only inference and not optimization passes by default, but @code_typed runs both. The thinking is that the output of code_warntype is easier to read if it's closer to the original code (inlining etc. can really do a number on it).

[jakobnissen]

This will be closed by #47574, if it gets merged.