Closed Bug 541288 Opened 14 years ago Closed 14 years ago

Log more information about what keeps what alive

Categories

(Core :: JavaScript Engine, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: bzbarsky, Assigned: bzbarsky)

Details

Attachments

(1 file)

In addition to logging which instructions are live, log which ones are keeping which other ones alive.
Attachment #422904 - Flags: review?
Attachment #422904 - Flags: review? → review?(nnethercote)
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.
> 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.
(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.
(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?
Attachment #422904 - Flags: review?(nnethercote) → review-
Done.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Er, let's try that again.
Resolution: FIXED → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: