use stmt instead of Instruction in populate_def_use_map!

[jumerckx]

fixes #56193

I imagine this maybe needs a test but not sure how to properly unit test this without creating a full end-to-end test using Base.code_ircode and so on.

[KristofferC]

@aviatesk, could you maybe have a look at this?

[aviatesk]

Yeah, I can take a look on this. Maybe tomorrow or so.

[LilithHafner]

Bump

[willtebbutt]

At least in my hands, the fix in this PR does indeed fix the problem, but it uncovers a separate issue at

julia/Compiler/src/optimize.jl

Lines 910 to 913 in 97c920d

	# bail out early if there are no possibilities to refine the effects
	if !any_refinable(sv)
	return nothing
	end

The problem appears to be the following: as a side-effect of calling ScanStmt, the first phase of the TwoPhaseDefUseMap (tpdum) associated to its sv field is performed during

julia/Compiler/src/optimize.jl

Line 869 in 97c920d

stmt_inconsistent = scan_inconsistency!(inst, sv)

i.e. it counts ssa uses -- see here .

Returning nothing on line 912 causes the underlying scan! to stop traversing the IRCode. This early stopping behaviour means that the tpdum can fail to properly count the number of uses associated to each SSA.

If this happens, it means that when CC.populate_def_use_map! is called here it has an underestimate of the total number of SSA uses, and will have incorrect counts in its ssa_uses field. Since CC.populate_def_use_map! definitely does a full pass over all (connected?) SSAs (since its call to scan! never returns nothing), it errors at some point when it tries to write to an element of tpdum.data which is beyond the end of the array.

In any case, one way to prevent this from happening is simply to not bail out early as part of calling a ScanStmt.

It makes sense that fixing CC.populate_def_use_map! would uncover this problem -- the fact that it wasn't previously ever attempting to write to tpdum.data due to the bug means that this problem would never happen.

I'm really struggling to generate a minimal reproducer for this -- I found this as part of my work on Mooncake.jl, and the example from which I figured out this behaviour involves a lot of algorithmically generated code, so isn't amenable to making a minimal reproducer. Does someone who knows more than me about this think that they have an obvious way to produce an minimal reproducer from this description?

edit: (I've confirmed locally that just commenting out lines 910-913 solves the problem, and have yet to encounter any new problems resulting from this)

edit2: there appear to be two more related places where uses can be missed. The first is another bailing-out-early example:

julia/Compiler/src/optimize.jl

Line 864 in 97c920d

return nothing

The second is that it looks like this bit of code assumes that the boundscheck argument to various things must be a constant, when in fact it looks like it can also be an SSA:

julia/Compiler/src/optimize.jl

Line 834 in 97c920d

for i = 1:(length(stmt.args)-1)