Skip to content

[Inference] Not all problems [...] can be solved by another level of indirection #31485

Closed

Description

@peterahrens encountered an interesting type-inference corner case, where adding a level of indirection would trigger type-inferences recursion heuristic and in his case prevent inlining to happen. The code Peter was written looked a lot like this:

f(arr::AbstractArray{T, 0}) where T = arr
indirect(arr) = f(arr)
f(arr::AbstractArray{T, N}) where {T, N} = indirect(view(arr, 1, ntuple(i->:, Val(N-1))...))

Inspecting this code with @code_typed f(zeros(3,3,3,3,3)) yields:

7 ─ %82 = invoke Main.f(%80::SubArray{Float64,4,Array{Float64,5},Tuple{Int64,Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}}},true})::SubArray{T,0,P,I,L} where L where I where P where T

whereas removing that level of indirection

f(arr::AbstractArray{T, 0}) where T = arr
f(arr::AbstractArray{T, N}) where {T, N} = f(view(arr, 1, ntuple(i->:, Val(N-1))...))

yields:

7 ─ %82 = invoke Main.f(%80::SubArray{Float64,4,Array{Float64,5},Tuple{Int64,Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}},Base.Slice{Base.OneTo{Int64}}},true})::SubArray{Float64,0,Array{Float64,5},NTuple{5,Int64},true}

The issue reminds me of #24852 and #26822

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions