Closed
Bug 541288
Opened 14 years ago
Closed 14 years ago
Log more information about what keeps what alive
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WONTFIX
People
(Reporter: bzbarsky, Assigned: bzbarsky)
Details
Attachments
(1 file)
4.21 KB,
patch
|
n.nethercote
:
review-
|
Details | Diff | Splinter Review |
In addition to logging which instructions are live, log which ones are keeping which other ones alive.
Assignee | ||
Comment 1•14 years ago
|
||
Attachment #422904 -
Flags: review?
Assignee | ||
Updated•14 years ago
|
Attachment #422904 -
Flags: review? → review?(nnethercote)
Comment 2•14 years ago
|
||
GCC gives lots of these warning: ../nanojit/LIR.cpp:1658: warning: format ‘%p’ expects type ‘void*’, but argument 3 has type ‘nanojit::LIns*’ Casting to void* is the easiest way to avoid it. Can you explain why do you want to see this output, how it would be useful to you? It doesn't seem to make the what-is-keeping-what-alive info any easier to read than the LIR itself; in fact I think it's worse because addresses are harder to read than identifiers.
Assignee | ||
Comment 3•14 years ago
|
||
> Casting to void* is the easiest way to avoid it. Sure, can do. > Can you explain why do you want to see this output, how it would be useful to > you? I originally wrote the patch when trying to figure out why a function call which is CSEable and whose return value was unused wasn't being eliminated. I don't see how the LIR itself would tell me which exact instructions are causing it to be kept... In my case, the use case would be a workflow like this: 1) See an instruction in the liveness output that I think should have been dead-code-eliminated. 2) Look at its address. 3) Grep the output this patch adds for that address. 4) See what instruction is keeping it alive and what its address is. 5) Repeat steps 3 and 4 until I find the relevant statement. If you don't think this is useful, can also wontfix this, of course. I just figured I should get the patch up in case it's useful to someone else.
Comment 4•14 years ago
|
||
(In reply to comment #3) > > I originally wrote the patch when trying to figure out why a function call > which is CSEable and whose return value was unused wasn't being eliminated. What was the reason? > In my case, the use case would be a workflow like this: > > 1) See an instruction in the liveness output that I think should have been > dead-code-eliminated. > 2) Look at its address. > 3) Grep the output this patch adds for that address. > 4) See what instruction is keeping it alive and what its address is. > 5) Repeat steps 3 and 4 until I find the relevant statement. > > If you don't think this is useful, can also wontfix this, of course. I just > figured I should get the patch up in case it's useful to someone else. It's narrow in its usefulness, and it's small enough that it's not hard to recreate if necessary, but it clutters up the output enough that if you don't care about it it's annoying. I vote for wontfix.
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #4) > What was the reason? Bug 536458. > It's narrow in its usefulness, and it's small enough that it's not hard to > recreate if necessary, but it clutters up the output enough that if you don't > care about it it's annoying. I vote for wontfix. OK. Want to do the deed?
Updated•14 years ago
|
Attachment #422904 -
Flags: review?(nnethercote) → review-
You need to log in
before you can comment on or make changes to this bug.
Description
•