JuliaDebug / JuliaDebug/Cthulhu.jl

Displays long chains of gotos not displayed by code-typed

Open
#352 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Julia
Stars
709
Forks
46
Avg merge
1d 13h
Merged PRs (30d)
2

Description

I think this might be something to do with the function doing a lot of inlining.
Consider code-typed:

julia> @code_typed (x->[x])(1)
CodeInfo(
1 ─ %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Int64}, svec(Any, Int64), 0, :(:ccall), Vector{Int64}, 1, 1))::Vector{Int64}
└──      goto #3 if not true
2 ─      Base.arrayset(false, %1, x, 1)::Vector{Int64}
3 ┄      goto #4
4 ─      return %1
) => Vector{Int64}

vs descend

julia> @descend (x->[x])(1)
(::var"#23#24")(x) @ Main REPL[42]:1
  ∘ ── %0 = invoke #23(::Int64)::Vector{Int64}                                                 
1 1 ── %1 = $(Expr(:foreigncall, :(:jl_alloc_array_1d), Vector{Int64}, svec(Any, Int64), 0, :(:ccall), Vector{Int64}, 1, 1))::Vector{Int64}
  2 ──      goto #3                                                                    ││╻╷╷╷╷   LinearIndices
  3 ──      goto #4                                                                    │││┃│││    axes
  4 ──      goto #5                                                                    ││││┃│      map
  5 ──      goto #6                                                                    │││││   
  6 ──      goto #7                                                                    ││││    
  7 ──      goto #8                                                                    │││     
  8 ──      nothing::Nothing                                                           │       
  9 ──      goto #10                                                                   │││╻╷╷╷╷   axes1
  10 ─      goto #11                                                                   ││││┃││     axes
  11 ─      goto #12                                                                   │││││┃       oneto
  12 ─      goto #13                                                                   │││││   
  13 ─      goto #14                                                                   ││││    
  14 ─      goto #15                                                                   │││     
  15 ─      nothing::Nothing                                                           │       
  16 ─      nothing::Nothing                                                           │       
  17 ─      Base.arrayset(false, %1, x, 1)::Vector{Int64}                              ││╻       setindex!
  18 ─      goto #19                                                                   ││      
  19 ─      return %1                                                                  │       
Select a call to descend into or ↩ to ascend. [q]uit. [b]ookmark.
Toggles: [o]ptimize, [w]arn, [h]ide type-stable statements, [d]ebuginfo, [r]emarks, [e]ffects, [i]nlining costs, [t]ype annotations, [s]yntax highlight for Source/LLVM/Native.
Show: [S]ource code, [A]ST, [T]yped code, [L]LVM IR, [N]ative code
Actions: [E]dit source code, [R]evise and redisplay
Advanced: dump [P]arams cache.

I assume this is to do with the info shown on the right (you will need to scroll across to see on github).
I think we should be willing to do some kind of goto compression (to match code_typed) at least by default

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Reproduce the discrepancy with @code_typed (x-> [x])(1) and @descend (x-> [x])(1), then trace how each view renders the control-flow blocks and the right-hand inlining information. Determine where long chains of gotos are displayed, and consider the issue resolved when the default descend display compresses such chains comparably to code_typed without hiding meaningful structure.

Written by the indexing model from the issue text.

Assessment

Tech stack
julia
Domain
devtools
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.