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

inference: track reaching defs for slots #55601

Draft
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

topolarity
Copy link
Member

@topolarity topolarity commented Aug 27, 2024

This PR implements the "Path-Convergence Criterion" for SSA / ϕ-nodes as part of type-inference.

The VarState.ssadef field corresponds to the "reaching definition" of the slot in SSA form, which allows us to conveniently reason about the identity of a slot across multiple program points. If the reaching def is equal at two program points, then the slot contents are guaranteed to be egal (i.e. x₀ === x₁)

Tasks:

  • Split StateRefinement change to separate PR
  • Split VarTable plumbing to separate PR
  • Remove old Conditional invalidation logic
  • Add tests

Fixes #55548 (alternative to #55551), by having Conditional remember the reaching definition that it narrows.

sa === sb && return sa
sa === NOT_FOUND && return sb
sb === NOT_FOUND && return sa
return VarState(tmerge(lattice, sa.typ, sb.typ), sa.undef | sb.undef)
return VarState(tmerge(lattice, sa.typ, sb.typ), sa.ssadef == sb.ssadef ? sa.ssadef : join_pc, sa.undef | sb.undef)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the core of the reaching def computation

It might be surprising that this doesn't use dominance, etc. but that's because dominance-based algorithms are optimized versions of the "path-convergence criterion" we solve here (both algorithms compute the same thing). Since we're solving the dataflow equations in this way for inference already, the SSA information comes mostly for free

This change effectively computes the SSA / ϕ-nodes for program slots as
part of type-inference, using the "path-convergence criterion" for SSA.

This allows us to conveniently reason about slot identity (in typical
SSA fashion) without having to quadratically expand all of our SSA type
state over the CFG.
Another change will probably be needed to make sure that `MustAlias`
itself is invalidated by `.defssa`, but this is enough to make sure that
any Conditional derived from MustAlias works correctly.
Copy link
Member

@aviatesk aviatesk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, this looks much better than my PR in general.
Still I would like to add the test case from it, i.e.

# JuliaLang/julia#55548: invalidate stale slot wrapper types in `ssavaluetypes`
_issue55548_proj1(a, b) = a
function issue55548(a)
    a = Base.inferencebarrier(a)::Union{Int64,Float64}
    if _issue55548_proj1(isa(a, Int64), (a = Base.inferencebarrier(1.0)::Union{Int64,Float64}; true))
        return a
    end
    return 2
end
@test Float64 <: Base.infer_return_type(issue55548, (Int,))

@@ -49,9 +49,9 @@ function abstract_eval_phi_stmt(interp::AbstractInterpreter, phi::PhiNode, ::Int
return abstract_eval_phi(interp, phi, nothing, irsv)
end

function abstract_call(interp::AbstractInterpreter, arginfo::ArgInfo, irsv::IRInterpretationState)
function abstract_call(interp::AbstractInterpreter, arginfo::ArgInfo, vtypes::Union{VarTable,Nothing}, irsv::IRInterpretationState)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
function abstract_call(interp::AbstractInterpreter, arginfo::ArgInfo, vtypes::Union{VarTable,Nothing}, irsv::IRInterpretationState)
function abstract_call(interp::AbstractInterpreter, arginfo::ArgInfo, ::Nothing, irsv::IRInterpretationState)

vtypes is never available for irinterp, so it's better to restrict this signature?

fargs = arginfo.fargs
if fargs !== nothing && 1 ≤ rt.slot ≤ length(fargs)
arg = ssa_def_slot(fargs[rt.slot], sv)
if isa(arg, SlotNumber)
argtyp = widenslotwrapper(arginfo.argtypes[rt.slot])
⊑ = partialorder(𝕃ᵢ)
if rt.vartyp ⊑ argtyp
return MustAlias(arg, rt.vartyp, rt.fldidx, rt.fldtyp)
@assert vtypes !== nothing
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better to check this at the topmost if condition?

@@ -512,7 +514,7 @@ function from_interconditional(𝕃ᵢ::AbstractLattice, @nospecialize(rt), sv::
if alias !== nothing
return form_mustalias_conditional(alias, thentype, elsetype)
end
return Conditional(slot, thentype, elsetype) # record a Conditional improvement to this slot
return Conditional(slot, vtypes[slot].ssadef, thentype, elsetype) # record a Conditional improvement to this slot
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We require vtypes !== nothing for this path.

Comment on lines +3653 to +3657
(thentype, elsetype) = if then_or_else === :then
(condt.thentype, Union{})
elseif then_or_else === :else
(Union{}, condt.elsetype)
else @assert false end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
(thentype, elsetype) = if then_or_else === :then
(condt.thentype, Union{})
elseif then_or_else === :else
(Union{}, condt.elsetype)
else @assert false end
if then_or_else === :then
thentype = condt.thentype
elsetype = Union{}
elseif then_or_else === :else
thentype = Union{}
elsetype = condt.elsetype
else @assert false end

the previous version creates Tuple objects whose types aren't known.

Comment on lines +55 to +56
`v.ssadef` represents the "reaching definition" for the variable. If negative, this refers
to a "virtual ϕ-block" preceding the given index. If a slot has the same `ssadef` at two
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What does "virtual φ-block" mean? I still don't quite grasp its meaning.
Also, it might be good to mention the case when ssadef == 0, meaning it was passed as an argument IIUC.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The "virtual ϕ-block" is just the usual block of ϕ-nodes that in proper SSA form would appear at the beginning of the BasicBlock. We're not actually inserting / re-indexing instructions though, so instead you get a negative index at the insertion point where the ϕ "would" go.

Also, it might be good to mention the case when ssadef == 0, meaning it was passed as an argument IIUC.

Yeah, great point - will do

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, well, is the use of the "virtual φ block" the same as the meaning of -pc passed to stupdate! in abstractinterpretation.jl? I might be misunderstanding, but my intuition is that negative ssadef means something like "we can't track the def of this slot." If that interpretation feels more natural, then maybe it would be better to represent it as ssadef::Union{Nothing,UInt}.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the same meaning as in stupdate!, but it doesn't mean "we can't track the def"

An ssadef of -pc means "If this code were in SSA form, a use of this slot would be replaced with a use of a ϕ-node." Which ϕ-node? The one that would have been inserted at pc

That's important because the rule given above:

If the reaching def is equal at two program points, then the slot contents are guaranteed to be egal (i.e. x₀ === x₁)

Also works for -pc ssadefs

@aviatesk
Copy link
Member

@nanosoldier runbenchmarks("inference", vs=":master")

@topolarity
Copy link
Member Author

topolarity commented Aug 29, 2024

Thanks for the test case and review @aviatesk

fwiw, there's also a precision regression that I encountered w/ this PR:

function foo()
    value = @noinline rand((true, false, 1))
    is_bool = value isa Bool
    if inferencebarrier(@noinline rand(Bool))
        value = 1.0
        is_bool = false
    end
    # at this merge point, only the "false half" of the Conditional should be invalidated
    return is_bool ? value : false
end
@assert only(Base.return_types(foo, ())) === Bool # fails w/ PR

but I think this can be mostly fixed by widening the Conditional at the merge point and giving it a new .ssadef to match

@nanosoldier
Copy link
Collaborator

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

@vtjnash
Copy link
Member

vtjnash commented Nov 18, 2024

bump? are we able to land this and backport to v1.11/v1.10?

@vtjnash vtjnash added compiler:inference Type inference bugfix This change fixes an existing bug labels Nov 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bugfix This change fixes an existing bug compiler:inference Type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Conditional lattice element is semantically broken in the presence of SSAValues
4 participants