Add debug info support for performance dump #249
Conversation
|
Note: the code uses the |
| return; | ||
| } | ||
|
|
||
| m_sourceFileName = std::string(path) + "/jit-" + std::to_string(m_pid) + "-codedump.txt"; |
There was a problem hiding this comment.
What is the purpose of m_sourceFileName?
Is this also related with perf tool?
And it seems that this file is opened, but not closed after execution.
There was a problem hiding this comment.
True, I will fix that. The purpose is generating a text dump from the Walrus byte code, and this "source" file is referred by the debug line info. In Walrus byte code, we cannot connect the original source in any way, but this way we still get info where the execution is mostly happens.
Example dump:
--- FUNCTION:5 [stackAlloc] ---
Prolog
[0] MoveI32: R0(r0)
[1] Const32: R0(imm)
[2] GlobalGet32: R0(r1)
[3] I32Sub: P0(r1), P1(r0), R0(r1)
[4] I32And: P0(r1), P1(imm), R0(r1)
[5] MoveI32: P0(r1), R0(r0)
[6] GlobalSet32: P0(r1), T0(r3)
[7] End: P0(r0)
Epilog
Example mixed code:
Percent│ [550] MoveF32: P0(r0), R0(o:152) ▒
0.16 │ movss %xmm0,0x98(%r15) ▒
│ [551] F32Store: P0(r9), P1(r0), T0(r1), T1(r2) ▒
│ mov %r13d,%esi ▒
│ mov 0x38(%rbx),%rax ▒
│ add $0x84,%rsi ▒
│ cmp $0xfffffc,%rsi ▒
│ → ja 3067 ▒
│ movss %xmm0,(%rax,%rsi,1) ▒
│ [552] F32Load: P0(r9), R0(o:144), T0(r1), T1(r2) ▒
│ mov %r13d,%esi ▒
│ mov 0x38(%rbx),%rax ▒
│ add $0x6c,%rsi ▒
│ cmp $0xfffffc,%rsi ▒
│ → ja 3067 ▒
0.32 │ movss (%rax,%rsi,1),%xmm4 ▒
│ movss %xmm4,0x90(%r15) ▒
│ [553] MoveF32: P0(o:168), R0(o:288) ▒
│ movss 0xa8(%r15),%xmm4 ◆
│ movss %xmm4,0x120(%r15) ▒
│ [554] F32Sub: P0(o:232), P1(o:212), R0(o:296) ▒
0.48 │ movss 0xe8(%r15),%xmm4 ▒
│ subss 0xd4(%r15),%xmm4 ▒
│ movss %xmm4,0x128(%r15)
There was a problem hiding this comment.
So, creating and using this 'source' file, we can analyze performance bottleneck of JIT code through perf tool, am I right?
There was a problem hiding this comment.
Yes. Without any source information, it is hard to figure out which machine code is generated from which byte code. This way at least we see the WebAssembly (Walrus to be more precise) byte code.
| @@ -314,16 +314,18 @@ void JITCompiler::insertStackInitList(InstructionListItem* prev, size_t variable | |||
| } | |||
| } | |||
|
|
|||
| const char* JITCompiler::m_byteCodeNames[] = { | |||
There was a problem hiding this comment.
m_byteCodeNames array is used only for dump.
For those debugging tools, what about dynamically allocating this array only when dump operation is initialized?
There was a problem hiding this comment.
I am not sure how can I do that. To do this dynamically, I need some static information, which can be used to generate this array. Shall we use some external file, which is processed at runtime? Or some kind of compressed data structure, which is uncompressed at runtime?
There was a problem hiding this comment.
I see
Instead of dynamic alloc, what about enabling these dump codes only for debug mode?
(using macro #ifndef NDEBUG)
There was a problem hiding this comment.
Yes. That means --jit-verbose will have no effect on release mode. I think that is acceptable.
There was a problem hiding this comment.
Can we enable all dump operations only for debug build?
There was a problem hiding this comment.
Yes, good idea. Now the byte code dump can be disabled even if perf dump is enabled.
zherczeg
force-pushed
the
perf_debug
branch
3 times, most recently
from
ee20b1c
to
b8e2c2f
Compare
Signed-off-by: Zoltan Herczeg zherczeg.u-szeged@partner.samsung.com
The code adds debug info support for jitdump, which helps analyzing performance bottlenecks. The source file for debugging is auto generated, since the jit compiler has access only to the walrus byte code. Depends on #244