debug metadata for inlined functions

[toivoh]

It seems that julia error tracebacks sometimes leave out some lines, including the one with the actual error.
When I load the following code from a script,

module M
function f()
    x        # line 3: error occurs here
end
function g()
    f()      # line 6
end
g()          # line 8
end

it produces the output

in g: x not defined
 in load at util.jl:230
 in load at util.jl:242
at /work/toivo/code/juliastuff/code/errorline.jl:8
 in load at util.jl:253

Note that both line 3, where the error occurs, and line 6, which calls it, are missing from the traceback.

[StefanKarpinski]

I suspect this is a side-effect of aggressive inlining, and therefore unlikely to go away. Unless you hate performance, of course ;-)

[pao]

It would be nice to make performance hating an option so we can get reasonable results in @debug.

[toivoh]

I see. No, I'm good with performance :)
Btw, julia's inlining or llvm's?
Still, when f and g get inlined into line 8, wouldn't it be possible to inline their line numbers along with them?
(E g save multiple source lines for one expression in this case)

[StefanKarpinski]

--hate

[StefanKarpinski]

I'm pretty sure this is Julia-level inlining. Honestly, I have no idea about this, I think that @JeffBezanson, @loladiro, or @vtjnash would have to chime in (I'm not sure why I think Keno or Jameson might know the answer, but I do).

[JeffBezanson]

Yes I can imagine sticking in some extra metadata along with inlined function bodies. It's a bunch of tedious work but totally doable.

[toivoh]

Sooner or later (v2.0?) that would be nice.
Until then, maybe a small gotchas section in the manual for these kind of things?

[jhasse]

What about adding a --debug command line switch for julia which enables a mode where performance is no longer the number 1 priority? In this debug mode functions wouldn't be inlined. Similar to GCC's -Wall -g versus -O2.

[StefanKarpinski]

Only if you like your programs taking thousands of years to run ;-)

Seriously, I think there's an (understandable) lack of appreciation of just how crucial inlining and other optimizations are in Julia. Julia without optimizations is much slower than the slowest interpreted language you can think of.

[jhasse]

Why is inlining so crucial for Julia? Other optimizations don't need to be turned off (as long as they don't break debug output).

[StefanKarpinski]

Because even something as basic as 1 + 2.5 goes through crazy layers of abstraction via promotion and conversion calls. Without inlining, it would be ridiculously slow – a dozen or more layers of function calls. Inlining is also important for exposing type information which is not an issue in statically typed languages. So it's not just a matter of eliminating function calls, but inlining also improves type information in the caller.

[jhasse]

I see. Thanks for explaining.

[vtjnash]

I've turned it off before. It wasn't that bad. Although building the system
image was harder without inlining, due to mutual dependencies.

[StefanKarpinski]

What were you running and how much slower was it?

[vtjnash]

So many questions.

I think I was just building the system image and some minor tests. There are tight inner loops that can be dramatically affected, but there aren't many of those in the sysimg build. Like vectorization (which this would prevent), it makes an enormous difference, but only in certain types of code which are relatively uncommon.

[mbauman]

I believe this can be closed since we now have the --inline=no option.

$ julia-0.4 --inline=no -q
julia> module M
       function f()
           x        # line 3: error occurs here
       end
       function g()
           f()      # line 6
       end
       g()          # line 8
       end
ERROR: UndefVarError: x not defined
 in f at none:3
 in g at none:6
 in eval at no file

[vtjnash]

Having a workaround isn't the same as fixing this

[mbauman]

Ah, right, sorry. As Jeff said:

Yes I can imagine sticking in some extra metadata along with inlined function bodies. It's a bunch of tedious work but totally doable.

[ihnorton]

Ref #12544 -- if we change the inlining pass in inference to allow :line nodes through then the situation should improve.

[ihnorton]

Fixed by @vtjnash in #13491 (with rabble-rousing moral support by me)

ERROR: UndefVarError: x not defined
 [inlined code] from none:3
 in g at none:6

(edit: nb, using @toivoh's original example)