Add profiler

[qwe661234]

Based on our observation, a high percentage of true hotspots involve loops or backward jumps, but the number of IR is unstable within these true hotspots.

Therefore, we believe our profiler can use three indices to detect hotspots:

1. Backward jump
2. Loop
3. Used frequency

Close: #189

[jserv]

Check #189 (comment) carefully. You should implement some of the following:

• Allow Linux perf to profile JITted code as QEMU.
• Generate profiling logs and use report program to view as mono does.
• Display in tree-based view as vmprof does.

It is important to provide interactive ways to browse profiling data with external tools. See All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more.

[qwe661234]

Check #189 (comment) carefully. You should implement some of the following:

• Allow Linux perf to profile JITted code as QEMU.
• Generate profiling logs and use report program to view as mono does.
• Display in tree-based view as vmprof does.

It is important to provide interactive ways to browse profiling data with external tools. See All my favorite tracing tools: eBPF, QEMU, Perfetto, new ones I built and more.

This runtime profiler serves as a trigger for the tier-1 JIT compiler. Do you mean we should provide a log mode for users to dump the profiling information?

[jserv]

This runtime profiler serves as a trigger for the tier-1 JIT compiler. Do you mean we should provide a log mode for users to dump the profiling information?

If you are going to close #189, you should consolidate the profiling facilities.

[qwe661234]

Currently, we only support for providing the information about branch, branch-untaken, and IRs of a basic block. I think we can create another issue for supporting visualizing graph IR.

[jserv]

1. Separate the processes of generating and rendering profiling data. Specifically, rv32emu (activated with the -p option) will be responsible for generating profiling data, while the rendering will be handled by the newly added tool rv_profile.
2. Ensure that block information, including the instructions (referencing ELF files for disassembly as needed), is captured as part of the profiling data. This approach will make the data more informative and valuable for analysis.
3. The proposed changes aim to equip the system with adequate capabilities for depicting runtime profiling information, a crucial aspect for ongoing JIT development.

[jserv]

The rationale behind segregating the generation and rendering of profiling data includes:

1. Enabling graphical representations without complicating the main rv32emu program.
2. Facilitating the use of tools like objdump for disassembling specific blocks, exemplified by commands such as objdump --start-address=0x50c40 --stop-address=0x50c60 -d.
3. Allowing for the profiling of RISC-V executables in a separate, offline run to collect profiling data. This data can then be utilized to assign accurate weights to the predecessors and successors in superoptimizers.

[qwe661234]

The rationale behind segregating the generation and rendering of profiling data includes:

1. Enabling graphical representations without complicating the main rv32emu program.
2. Facilitating the use of tools like objdump for disassembling specific blocks, exemplified by commands such as objdump --start-address=0x50c40 --stop-address=0x50c60 -d.
3. Allowing for the profiling of RISC-V executables in a separate, offline run to collect profiling data. This data can then be utilized to assign accurate weights to the predecessors and successors in superoptimizers.

1. We can achieve this by writing a python script to parse generated profiling data.
2. We need another debug mode for this? because we don't have debug mode currently.

[jserv]

1. We can achieve this by writing a python script to parse generated profiling data.

Yes, you can write a Python-based renderer for profiling data.

2. We need another debug mode for this? because we don't have debug mode currently.

No, you can specify the start/stop address for objdump -d without any debugging symbols.

[qwe661234]

Facilitating the use of tools like objdump for disassembling specific blocks, exemplified by commands such as objdump --start-address=0x50c40 --stop-address=0x50c60 -d.

Does you means this function supports for providing the instruction sequence of a basic block starting from address start-address without other profiling data?

[jserv]

Does you means this function supports for providing the instruction sequence of a basic block starting from address start-address without other profiling data?

It depends on the format/layout of profiling data recorded during the execution of RISC-V programs. You can simply record the entry/exit address of each block, so that you can consult binutils.

[qwe661234]

Currently, the profiler script support for:

1. printing profiling data from start_address to stop_address
2. visualizing graph IR of the specficed program counter like example below