-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
Emit inlining information to improve line numbers #12544
Conversation
Would be better to construct a backtrace for inline functions as well but this is very nice to have. Can the profiling system take advantage of this? |
Didn't look in details but I'd be glad to have it as well. I don't think there will be much conflict but can this be done on top of the codegen rewrite ? Even if it should not really touch the same parts I think it's good in general. (Might also help in getting it merged ;-)) |
I'm honored that you thought my Seriously, this is really nice---a huge gain in terms of usability. |
🍰 |
👏 |
@timholy I forgot to mention, this works with
@carnaval it should be trivial to rebase on the codegen rewrite if needed, there's only about ~10 loc change in codegen. |
@@ -4502,6 +4502,7 @@ static Function *emit_function(jl_lambda_info_t *lam) | |||
int prevlno = -1; | |||
for(i=0; i < stmtslen; i++) { | |||
jl_value_t *stmt = jl_cellref(stmts,i); | |||
/* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this block just be deleted, or does it need to be brought back?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Forgot about this. If Jeff approves the parser change then all LineNode-handling code can be deleted.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see what is controversial about the LineNode change.
since this touches only the debuginfo parts of codegen, i expect it will merge cleanly with my codegen restructuring PR. |
8a94a36
to
b3d0e4a
Compare
@vtjnash shhh don't tell, I thought if we pile up PRs depending on this one it would get merged faster |
Test failures are fixed. |
Sweet! Will be good to squash out the failing commits. |
b3d0e4a
to
e2d7bfe
Compare
Squashed, rebased, |
You have a whitespace error. Why wouldn't we merge this? 0.4 will probably be at least 8-12 months, so it seems worth it to have better debug info during that time. |
Well I (and many other people) would very much appreciate backtraces working with macros in 0.4, but I'm not in a position to judge how risky it is to merge this. |
Anything to make line numbers better is worth it |
e2d7bfe
to
093d1b2
Compare
Since we seem to be taking longer to branch than I expected, then heck, if it's all working there's no reason to have this languish (I'm not really qualified to review it). I recognize touching codegen is risky, but this is a pretty big usability problem (I had someone in my lab ask about this just today). |
I'm in favor of merging if @ihorton thinks it's safe. |
9ec72c0
to
6d5b7a1
Compare
I am comfortable merging this, but would appreciate a once-over/thumbs-up from anyone who can review (especially the changes to ast.c and codegen.cpp). |
|
||
try | ||
testinline() | ||
catch err |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LoadError("C:\projects\julia\test\backtrace.jl",18,ErrorException("invalid redefinition of constant err"))
looks like CI wants you to pick a different name here (or add err to the let block variable list)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
must be an ordering thing because it did pass on several workers. I just added err
to the let
block, and also mimicked the handling in replutil (skip fromC
and :error
frames) because I don't think bt[4]
is accurate for all platforms (namely win32).
this looks ready to merge to me. it looks like someone will need to deal with some merge conflict on the command line though to push it to master. |
👍 |
@@ -222,7 +222,7 @@ function poplinenum(ex::Expr) | |||
if ex.head == :block | |||
if length(ex.args) == 1 | |||
return ex.args[1] | |||
elseif length(ex.args) == 2 && ex.args[1].head == :line | |||
elseif length(ex.args) == 2 && isa(ex.args[1], LineNumberNode) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this need to work on surface syntax ASTs? (used from macros)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fixed (I think). Thanks.
What's the impact on the size of the system image? |
|
||
if (inlinedfile != symbol("")) | ||
print(io, " at ", inlinedfile, ":", inlinedline) | ||
print(io, " \n [ thrown by inlined function defined at ]\n ") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find this output a bit confusing. Since the brackets close before all the info is printed, it looks like the location is simply missing. I would print it something like in inlined function defined at file:line
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how about by code inlined from
? could be from macro or inline.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that makes sense.
Utilizes the DebugLoc "inlinedAt" parameter to remember inlining location in addition to source code origin. When available, we now print both the inlinee origin below the top-level call site. Mostly addresses #1334. (this does not handle nested inlines, which may require deeper changes)
~ 700k
|
7aa2dd3
to
013f906
Compare
Rebased. |
013f906
to
c1ded2e
Compare
@@ -134,8 +136,8 @@ maxlen_data() = convert(Int, ccall(:jl_profile_maxlen_data, Csize_t, ())) | |||
|
|||
function lookup(ip::Ptr{Void}) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably make more use of this interface to jl_lookup_code_address
.
Hmm, I guess 2-3% isn't so bad. The |
(quick&dirty test: lz4 shrinks sys.so by 4x and only takes ~50ms to decompress, so it might be easier than spending too much time improving the serializer) |
- renamed inlinedfile/line -> inlinedat_file/line - update inlining message - fix poplinenum.
c1ded2e
to
19e765e
Compare
Nothing of substance to add, but I found this branch to be exceedingly useful to profile some macro heavy code that previously reported complete nonsense. I'm unreasonably excited to see it merged. |
…-to-linenode Emit inlining information to improve line numbers
Woot! Didn't expect this to make it in. But really looking forward to it (building now). |
👍 💯 👏 🎉 |
Also changes the parser to include file information with every linenode (see #1334 (comment))
before (Tim's example):
after:
over 5 runs rebuilding sysimg I get average times of:
master: 81.328s (max: 82.28)
branch: 81.846s (max: 82.76)
so, +.48s to rebuild sysimg (also +9MB max resident RAM)