Skip to content

Support debuginfo context option in IRShow for IRCode/IncrementalCompact #58642

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

Merged
merged 4 commits into from
Jul 3, 2025

Conversation

serenity4
Copy link
Member

@serenity4 serenity4 commented Jun 4, 2025

This allows us to get complete source information during printing for IRCode and IncrementalCompact, same as we do by default with CodeInfo.

The user previously had to do:

Compiler.IRShow.show_ir(stdout, ir, Compiler.IRShow.default_config(ir; verbose_linetable=true))

and now, they only need to do:

show(IOContext(stdout, :debuginfo => :source), ir)

@Keno
Copy link
Member

Keno commented Jun 4, 2025

show(IOContext(stdout, :verbose_linetable => true), ir)

Or put it in the their global repl iocontext if they want it always and to apply to e.g. display.

@topolarity
Copy link
Member

What do you think about debuginfo = :source (matching what code_typed et al accept), instead of verbose_linetable = true?

I would expect the latter to print a representation of the linetable itself, so it's a bit of a misnomer

@serenity4
Copy link
Member Author

I agree that the current naming is not great. If we go with debuginfo = :source for the case verbose_linetable === true, the case verbose_linetable === false could be defined as debuginfo = :inline (or debuginfo = :source_inline).

@topolarity
Copy link
Member

That sounds all right to me.

Out of curiosity, how do we handle the inline vs. linetable debuginfo issue for the conversion from IRCode to CodeInfo right now?

@serenity4
Copy link
Member Author

serenity4 commented Jun 5, 2025

I'm not sure I see what you mean? AFAIK both IRCode and CodeInfo have the same DebugInfo representation, except that IRCode holds it uncompressed.
And here in the display, it's just a matter of printing.

@topolarity
Copy link
Member

AFAIK both IRCode and CodeInfo have the same DebugInfo representation

Ah, you're right. I forgot about that. I was thinking about how inference fills this in at the end:

debuginfo = get_debuginfo(inferred_result)
# Inlining may fast-path the global cache via `VolatileInferenceResult`, so store it back here
result.src = inferred_result
else
if isa(result.src, OptimizationState)
debuginfo = get_debuginfo(ir_to_codeinf!(result.src))
elseif isa(result.src, CodeInfo)
debuginfo = get_debuginfo(result.src)
end
but it does that regardless of whether we optimize so it's always there when we emit the final CodeInfo.

@serenity4
Copy link
Member Author

That's correct. Seeing the line get_debuginfo(ir_to_codeinf!(result.src)) , I'm thinking we don't even need to turn IRCode into CodeInfo to get its debuginfo (we just need to compress it), but for NativeInterpreter it's still best to use ir_to_codeinf! performance-wise as it is cached and we'll be also calling that ~40 lines of code after.

For verbose_linetable, as it's not documented and fairly internal I guess we can break it and replace it with debuginfo = [:none|:source_inline|:source]? Then I think we can add :source_inline printing to CodeInfo as well and support that in @code_typed etc.

@serenity4
Copy link
Member Author

Then I think we can add :source_inline printing to CodeInfo as well and support that in @code_typed etc.

It's a bit more complicated actually, because we don't have control over the IOContext in which the results are shown, meaning we must actually delete debuginfo (for :none) or leave it as is (for :source). We can't specify how it must print later on.

@serenity4
Copy link
Member Author

serenity4 commented Jun 5, 2025

It appears we have two different semantics for a debuginfo parameter:

  • Preserve/discard debuginfo information (current behavior of @code_typed)
  • Control what to print (actually the semantic people expect for @code_typed)

The mismatch between the two expectations in the current state means that we must always show CodeInfo with debuginfo=:source by default (so when printing, if debuginfo information was discarded, it will correctly display none). It's not great but I don't think we can do anything reasonable to improve the status quo.

Therefore I'll go with only supporting a debuginfo context for IRCode/IncrementalCompact (and to some extent CodeInfo but only via show_ir).

@serenity4 serenity4 changed the title Support verbose_linetable context option in IRShow Support debuginfo context option in IRShow for IRCode/IncrementalCompact Jun 5, 2025
@serenity4
Copy link
Member Author

@topolarity shall we merge this?

@topolarity
Copy link
Member

we must always show CodeInfo with debuginfo=:source by default (so when printing, if debuginfo information was discarded, it will correctly display none)

This seems strange to me - is it really not possible to mark the debuginfo as discarded and display it "correctly"?

It does make sense that dropping debuginfo in the presentation layer vs. the CodeInfo / IRCode generation would be different things, but I'm not sure I understand why CodeInfo is different than IRCode / IncrementalCompact in that respect

@serenity4
Copy link
Member Author

serenity4 commented Jul 3, 2025

This is specifically relevant to @code_typed/code_typed, because the reflection function has no control over the user's display (IO context), yet the debuginfo parameter set expectations on what is printed.

Essentially, if we don't special-case CodeInfo, this means that src = @code_typed debuginfo=:source f() may return a src that doesn't print with debuginfo = :source, if the user set a context of :debuginfo => :inline_source or :debuginfo => :none.

I don't think we should make CodeInfo specify in its fields how to be printed. In my opinion the one at fault is @code_typed which sets a printing expectation without actually having control over printing.

@serenity4
Copy link
Member Author

IRCode / IncrementalCompact are not affected because there is no reflection function that sets this expectation (code_ircode does not support debuginfo as a parameter).

@topolarity topolarity merged commit 32211a6 into master Jul 3, 2025
7 checks passed
@topolarity topolarity deleted the verbose-linetable-ioctx branch July 3, 2025 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants