assignment out of an inner function leads to unnecessary boxing

[aviatesk]

This may have been filed already, but let me file it here anyway as I couldn't find existing issue:

julia> function f(c, x)
           local var = nothing
           if c
               var = Any[]
           end
           function usevar(x)
               if var !== nothing
                   push!(var, x)
                   return var
               else
                   return nothing
               end
           end
           return usevar(x)
       end
f (generic function with 1 method)

julia> code_lowered(f, (Bool,Int))
1-element Vector{Core.CodeInfo}:
 CodeInfo(
1 ─      var = Core.Box()
│        Core.NewvarNode(:(usevar))
│   %3 = Main.nothing
│        Core.setfield!(var, :contents, %3)
└──      goto #3 if not c
2 ─ %6 = Base.getindex(Main.Any)
└──      Core.setfield!(var, :contents, %6)
3 ┄      usevar = %new(Main.:(var"#usevar#3"), var)
│   %9 = (usevar)(x)
└──      return %9
)

I'm willing to look at improving the lowering implementation if anyone kindly tell me which part of our codebase should be modified.

[jakobnissen]

Isn't this an instance of the infamous "slow closure bug"? #15276

[aviatesk]

I'm kind of interested in what actual changes are needed to fix those examples.
Not all outer assignment causes boxing, e.g.:

julia> function f(c, x)
           # local var = nothing
           # if c
           #     var = Any[]
           # end
           var = Any[]
           function usevar(x)
               if var !== nothing
                   push!(var, x)
                   return var
               else
                   return nothing
               end
           end
           return usevar(x)
       end
f (generic function with 1 method)

julia> code_lowered(f, (Bool,Int))
1-element Vector{Core.CodeInfo}:
 CodeInfo(
1 ─      var = Base.getindex(Main.Any)
│   %2 = Main.:(var"#usevar#3")
│   %3 = Core.typeof(var)
│   %4 = Core.apply_type(%2, %3)
│        usevar = %new(%4, var)
│   %6 = (usevar)(x)
└──      return %6
)

so it seems that some general fix is needed here, but rather we want to fix these example one by one?

[jakobnissen]

There is a section on this in the Julia docs performance tips. I'm not deeply into the codebase, but as far as I have heard other people talk about it, the problem is that at the lowering stage, there is no type info, so Julia does not know if var can change type in the if statement. Therefore, it emits a box.

The fix is supposedly to rewrite the lowering step in Julia - but I'm sure the other compiler devs have thought quite a lot about this bug

[aviatesk]

the problem is that at the lowering stage, there is no type info, so Julia does not know if var can change type in the if statement. Therefore, it emits a box.

Well, as far as all the assignments happens out side of the scope of inner function, we can safely unbox it? Maybe I should better read through the code base though. This seems to be very much an implementation detail.

[KristofferC]

There is a section on this in the Julia docs performance tips. I'm not deeply into the codebase, but as far as I have heard other people talk about it, the problem is that at the lowering stage, there is no type info, so Julia does not know if var can change type in the if statement. Therefore, it emits a box.

Just pointing it out explicitly, there is no re-assignment to the variable inside the closure in this case.

[CameronBieganek]

The fix is supposedly to rewrite the lowering step in Julia

IIUC, rewriting parsing and lowering in Julia (i.e. JuliaSyntax) is just a (preferred) prerequisite for solving this problem. Doing the same lowering in Julia that FemtoLisp does will not of course solve the problem.

[maleadt]

parsing and lowering in Julia (i.e. JuliaSyntax)

FWIW, JuliaSyntax is only parsing, not lowering. There are no plans to port lowering to Julia.

[vtjnash]

Duplicate of #15276