716251 - IonMonkey: improve assembly output

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Jan de Mooij [:jandem]]

When fixing correctness/performance bugs, it's often useful to look at the generated code. With the JMFLAGS=insns mechanism it can be hard to locate the code for a certain instruction.

The easiest approach is to have CodeGenerator spew the name of LIR instructions and out-of-line paths, comparable to JM's "ops" output. Another approach is to import a disassembler or something.

Any suggestions?

Comment 1

[Nicolas B. Pierron [:nbp]]

(In reply to Jan de Mooij (:jandem) from comment #0)
> When fixing correctness/performance bugs, it's often useful to look at the
> generated code. With the JMFLAGS=insns mechanism it can be hard to locate
> the code for a certain instruction.

The problem are that the output does not represent one stream of instruction and labels are hard to follow.  For example with generateVMWrapper, which may produce assembly in another buffer, the wrapper assembly get ""inline"" in the output of the current jitted function, which makes both unreadable.  I would be better to store this output somewhere and print it once the buffer is finalize.

> The easiest approach is to have CodeGenerator spew the name of LIR
> instructions and out-of-line paths, comparable to JM's "ops" output. Another
> approach is to import a disassembler or something.
> 
> Any suggestions?

What I use is gdb, I usually do the following commands when I have to debug:

(gdb) break js::ion::CodeGenerator::visitStart
(gdb) command
> call masm.breakpoint()
> continue
> end
(gdb) …

// when it stop at visitStart
(gdb) x /i50 $pc  # or disas $pc, +100