Compiler optimization for ScopedValues

[vchuravy]

It might be beneficial to perform some optimization over scoped values.

In particular it would be beneficial for the value lookup to be coalesced within a dynamical scope.
This would require them to be CSE'd or for GVN (#51120) to be aware of their semantics.

We would need to annotate in the IR the extent of a dynamical scope, since
since ScopedValue are only constant within that region.

token = Expr(:dynamical_scope_enter, args::Pair{ScopedValue, Any}...)
...
Expr(:dynamical_scope_exit, token)

This might be a bit frustrating since currently we have:

current_scope = current_task().scope
current_task().scope = Scope(...)
try
finally
      current_task().scope = current_scope
end

and thus we would introduce a "silent" new form of a try...finally block which seems not ideal.

But maybe a representation like:

old_scope = Expr(:dynamical_scope_enter, args::Pair{ScopedValue, Any}...)
try
finally
    Expr(:dynamical_scope_exit, old_scope)
end

Could still work?

Of course this is predicated on how folks are using ScopedValues in the wild to determine if this would be useful at all.
Java seems to do this kind of optimization + a very small cache.

[simonbyrne]

Somewhat related, but we could make scoped variables a language feature (possibly in Julia 2.0?). i.e. instead of

const var = ScopedValue{T}(default)
with(var => newval) do
   x = var[]
end

we could have

scoped var::T = default
with var = newval
   x = var
end

[serenity4]

What type of code would benefit from these optimizations? Would that include e.g. the following:

const S = ScopedValue(0)

g() = S[] + 1

function f()
  @with S => 1 begin
    g()
  end
end

f()

which would be able to const-prop the result to 2?

It seems to me that, for cases where e.g. g() is not inlineable, it might require a separate compilation for every possible scoped value and MethodInstance pair (S, g()) within a given world age, which might negatively affect compilation times.

Although, if we are able to detect that a hypothetical method called by g(), say h(x), does not rely on scoped values at all, we don't need to compile h(x) twice for two different scoped values S. I guess with some cleverness the problem then goes away.

[vchuravy]

which would be able to const-prop the result to 2?

Note that scoped values are constant within a certain scope, so your code as written does not work.

But yes the goal would be that we could constant partially const-prop.

If g is not inlineable, we wouldn't know the value, but we would still be able to merge multiple accesses of the same scoped value.

[serenity4]

Note that scoped values are constant within a certain scope, so your code as written does not work.

What do you mean? This seems to work fine:

julia> const S = ScopedValue(0)
ScopedValue{Int64}(0)

julia> g() = S[] + 1
g (generic function with 1 method)

julia> function f()
         @with S => 1 begin
           g()
         end
       end
f (generic function with 1 method)

julia> f()
2

[vchuravy]

Ah sorry I read g() = S[] + 1 as g() = S[] += 1

[Keno]

I'm planning to address this as follows:
Once #51754 is merged, extend the :enter form to take an additional argument that implicitly sets the scope. Then we can extend SROA to forward scope enters to scope reads (and exception throws to :the_exception). :leave would pop the current scope automatically and direct setfield of the scope on a running task would be considered illegal.

[Keno]

I'm gonna call this addressed. ScopedValues are pretty well optimizable at this point.