Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimizer: enable SROA of mutable φ-nodes #43505

Open
wants to merge 1 commit into
base: avi/multisroa
Choose a base branch
from

Commits on Jan 8, 2022

  1. optimizer: enable SROA of mutable φ-nodes

    This commit allows elimination of mutable φ-node (and its predecessor mutables allocations).
    As an contrived example, it allows this `mutable_ϕ_elim(::String, ::Vector{String})`
    to run without any allocations at all:
    ```julia
    function mutable_ϕ_elim(x, xs)
        r = Ref(x)
        for x in xs
            r = Ref(x)
        end
        return r[]
    end
    
    let xs = String[string(gensym()) for _ in 1:100]
        mutable_ϕ_elim("init", xs)
        @test @allocated(mutable_ϕ_elim("init", xs)) == 0
    end
    ```
    
    This mutable ϕ-node elimination is still limited though.
    Most notably, the current implementation doesn't work if a mutable
    allocation forms multiple ϕ-nodes, since we check allocation eliminability
    (i.e. escapability) by counting usages counts and thus it's hard to
    reason about multiple ϕ-nodes at a time.
    For example, currently mutable allocations involved in cases like below
    will still not be eliminated:
    ```julia
    code_typed((Bool,String,String),) do cond, x, y
        if cond
            ϕ2 = ϕ1 = Ref(x)
        else
            ϕ2 = ϕ1 = Ref(y)
        end
        ϕ1[], ϕ2[]
    end
    
    \# more realistic example
    mutable struct Point{T}
        x::T
        y::T
    end
    add(a::Point, b::Point) = Point(a.x + b.x, a.y + b.y)
    function compute(a::Point{ComplexF64}, b::Point{ComplexF64})
        for i in 0:(100000000-1)
            a = add(add(a, b), b)
        end
        a.x, a.y
    end
    ```
    
    I'd say this limitation should be addressed by first introducing a better
    abstraction for reasoning escape information. More specifically, I'd like
    introduce EscapeAnalysis.jl into Julia base first, and then gradually
    adapt it to improve our SROA pass, since EA will allow us to reason about
    all escape information imposed on whatever object more easily and should
    help us get rid of the complexities of our current SROA implementation.
    
    For now, I'd like to get in this enhancement even though it has the
    limitation elaborated above, as far as this commit doesn't introduce
    latency problem (which is unlikely).
    aviatesk committed Jan 8, 2022
    Configuration menu
    Copy the full SHA
    bf97c29 View commit details
    Browse the repository at this point in the history