invert linetable representation

[vtjnash]

Previously, our linetables (similar to LLVM) represented line information as a linked list from callee via inlined_at up to the original information. This requires many copies of this information to be created. Instead we can take advantage of the necessary existence of the line table from the child to flip this chain of information and instead make each statement be a table describing (for each IR instruction):
(current line number, (index into edges, index into edges statements)) plus a table of all edges, plus a table with the original line numbers from the parser, plus the file name. This is all packed into the struct

struct DebugInfo
    def::Union{Method,MethodInstance,Symbol}
    linetable::Union{Nothing,DebugInfo}
    edges::SimpleVector{DebugInfo}
    codelocs::String
end

Which is described in doc/src/devdocs/ast.md for what each field means and look at stacktraces.jl or compiler/ssair/show.jl to look at how to decode and interpret this information.

For the sysimage, this saves several megabytes (about 113 MB -> 110 MB) and about 5% of the stdlib pkgimages (294 MB -> 279 MB).

It also now happens to have the full type information for the inlined functions. Now if you create an IRShow.DILineInfoPrinter with showtypes=true, it can print that information when printing IR.

Opening as draft, although it is hopefully ready for review, since it appears there will be an update needed to keep Revise working with the new format for this info.

julia> @eval Base.IRShow DILineInfoPrinter(debuginfo, def) = DILineInfoPrinter(debuginfo, def, true)
DILineInfoPrinter (generic function with 2 methods)

julia> (@code_typed 1 + 1.0)[1]
CodeInfo(
    @ promotion.jl:425 within `+`
   ┌ invoke MethodInstance for promote(::Int64, ::Float64)
   │ @ promotion.jl:396 within `promote`
   │┌ invoke MethodInstance for Base._promote(::Int64, ::Float64)
   ││ @ promotion.jl:373 within `_promote`
   ││┌ invoke MethodInstance for convert(::Type{Float64}, ::Int64)
   │││ @ number.jl:7 within `convert`
   │││┌ invoke MethodInstance for Float64(::Int64)
   ││││ @ float.jl:221 within `Float64`
1 ─││││ %1 = Base.sitofp(Float64, x)::Float64
│  └└└└
│  ┌ invoke MethodInstance for +(::Float64, ::Float64)
│  │ @ float.jl:460 within `+`
│  │ %2 = Base.add_float(%1, y)::Float64
│  └
└──      return %2
)

[JeffBezanson]

I like this; feels like a real improvement. Just need to figure out some details and how much we care about compatibility of code that handles IR.

[vtjnash]

compatibility of code that handles IR.

Thanks! As long as code has been using the Compiler APIs, they should not be much affected. It is rare for code to need to "invent" a novel line number. Inlining does it in some specific ways, but generally code should not do it otherwise, as lines should come from the user, which is what I wanted to better reflect here, compared to what I felt that inlined_at had done previously.

[timholy]

I can't pretend to have read the whole thing carefully, but the overall concept seems great. Merely having the type info available for inlining is a huge win on its own. I'll certainly make any needed changes to the Revise stack when this gets merged.

My comments are mostly about the clarity of the documentation.

[vtjnash]

I was testing Revise on this branch earlier to see if I needed to make a PR there, and I think this PR already resolved a lot of the issues with it: JuliaDebug/JuliaInterpreter.jl#606. Looks like there are a few other failing test now (since it type-asserts the kind of something and doesn't know about the new Base.IRShow.LineInfoNode). They look minor, but let me know if something isn't clear.

[timholy]

When we get a better way of tracking "provenance" (e.g., #31162) through lowering, will this make it easier to extend it all the way through the IRCode representation? It seems plausible to me that it will. Someday we should write an IRCode interpreter, I expect that to be much faster than any interpreter we have now. But it's kinda useless if you can't track whatever you're evaluating back to the original source code.

[vtjnash]

This already does that in fact. Every statement refers back to the IR statement it was originally from, including the inlining info, instead of the line numbers (only the original statement then has the line number). It isn't one-to-one precise though (as various transforms may combine or delete statements), and doesn't alter lowering to track it back to the AST.

[timholy]

Right. All that sounds great. Looking forward to this and to getting similar things done for lowering too---it will expand the tooling options considerably.

[topolarity]

Is it worth giving these (line, edge, edge_line) triplets a name?

I had to do a fair bit of digging to figure out how to interpret them

[vtjnash]

Isn't that covered in the documentation here already?

[vtjnash]

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