Page MenuHomePhabricator

Add disassembly counter after disasembly line
Needs ReviewPublic

Authored by jiaolu on Oct 2 2020, 9:10 PM.

Details

Summary

This would make it easier for the AMDGPU shader debugging or
shader replacement at particular position.

Disassembly line would look like:

Before:

v_add_nc_u32_e32 v0, 0xd10, v4    ; 4A0008FF 00000D10

After:

v_add_nc_u32_e32 v0, 0xd10, v4    ; 00000004: 4A0008FF 00000D10

Diff Detail

Unit TestsFailed

TimeTest
850 mslinux > libarcher.parallel::parallel-nosuppression.c
Script: -- : 'RUN: at line 15'; /mnt/disks/ssd0/agent/llvm-project/build/./bin/clang -fopenmp -pthread -fno-experimental-isel -g -O1 -fsanitize=thread -I /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests -I /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/runtime/src -L /mnt/disks/ssd0/agent/llvm-project/build/lib -Wl,-rpath,/mnt/disks/ssd0/agent/llvm-project/build/lib /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests/parallel/parallel-nosuppression.c -o /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/tools/archer/tests/parallel/Output/parallel-nosuppression.c.tmp -latomic && env TSAN_OPTIONS='ignore_noninstrumented_modules=0' /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/tools/archer/tests/parallel/Output/parallel-nosuppression.c.tmp 2>&1 | tee /mnt/disks/ssd0/agent/llvm-project/build/projects/openmp/tools/archer/tests/parallel/Output/parallel-nosuppression.c.tmp.log | /mnt/disks/ssd0/agent/llvm-project/build/./bin/FileCheck /mnt/disks/ssd0/agent/llvm-project/openmp/tools/archer/tests/parallel/parallel-nosuppression.c

Event Timeline

jiaolu created this revision.Oct 2 2020, 9:10 PM
Herald added a project: Restricted Project. · View Herald TranscriptOct 2 2020, 9:10 PM
jiaolu requested review of this revision.Oct 2 2020, 9:10 PM

I don't understand how this would help with shader replacement. Can you please explain how you plan to use this?

llvm/lib/Target/AMDGPU/AMDGPUAsmPrinter.h
149

The name is too unspecific. Suggestion: DisasmNumBytes.

arsenm requested changes to this revision.Oct 12 2020, 10:04 AM

Please work on removing this feature from the backend instead. It's long past time to stop handling this in the compiler

This revision now requires changes to proceed.Oct 12 2020, 10:04 AM

Please work on removing this feature from the backend instead. It's long past time to stop handling this in the compiler

There are several shader debugger tools/situation dependent on this feature.
e.g. one line like this "s_andn2_b32 vcc_lo, vcc_lo, 0 ;000974: 8A6A806A"
1). we feed the disassembly count "0x000974" to the shader debugger tool to get this line of code execution ,register input and output.
2).Also there is some other shader dump tool,e.g. umr. or windbg which output a stream of hardware codes, we can use the hardware code to find matched part of disassembly lines.
3). we also have one shader replacement tool , to drop and replace part of the elf hardware code, if we have full disassembly line with counter and hardware code, it would be handy where to edit hardware code.

Hope it explains.

I don't understand how this would help with shader replacement. Can you please explain how you plan to use this?

s_getpc_b64 s[10:11] ; 00000000: BE8A1F00
s_mov_b32 s15, 0x21014fac ; 00000004: BE8F03FF 21014FAC
s_mov_b64 s[0:1], s[10:11] ; 0000000C: BE80040A
s_mov_b32 s0, s5 ; 00000010: BE800305
s_mov_b32 s14, -1 ; 00000014: BE8E03C1

DisasmNumBytes seems to means summary values, this variable means to tell you where the disassembly line position is in the code body,
If you don't like DisasmCounter , maybe DisasmOffset is better name?

Please work on removing this feature from the backend instead. It's long past time to stop handling this in the compiler

There are several shader debugger tools/situation dependent on this feature.
e.g. one line like this "s_andn2_b32 vcc_lo, vcc_lo, 0 ;000974: 8A6A806A"
1). we feed the disassembly count "0x000974" to the shader debugger tool to get this line of code execution ,register input and output.
2).Also there is some other shader dump tool,e.g. umr. or windbg which output a stream of hardware codes, we can use the hardware code to find matched part of disassembly lines.
3). we also have one shader replacement tool , to drop and replace part of the elf hardware code, if we have full disassembly line with counter and hardware code, it would be handy where to edit hardware code.

Hope it explains.

It doesn't really. If you already parse this text output, surely you could just derive the offset yourself by counting the number of dwords in comments?

Please work on removing this feature from the backend instead. It's long past time to stop handling this in the compiler

There are several shader debugger tools/situation dependent on this feature.
e.g. one line like this "s_andn2_b32 vcc_lo, vcc_lo, 0 ;000974: 8A6A806A"
1). we feed the disassembly count "0x000974" to the shader debugger tool to get this line of code execution ,register input and output.
2).Also there is some other shader dump tool,e.g. umr. or windbg which output a stream of hardware codes, we can use the hardware code to find matched part of disassembly lines.
3). we also have one shader replacement tool , to drop and replace part of the elf hardware code, if we have full disassembly line with counter and hardware code, it would be handy where to edit hardware code.

Hope it explains.

You can disassemble the text section in the tooling. The compiler does not need to provide this at all

Please work on removing this feature from the backend instead. It's long past time to stop handling this in the compiler

There are several shader debugger tools/situation dependent on this feature.
e.g. one line like this "s_andn2_b32 vcc_lo, vcc_lo, 0 ;000974: 8A6A806A"
1). we feed the disassembly count "0x000974" to the shader debugger tool to get this line of code execution ,register input and output.
2).Also there is some other shader dump tool,e.g. umr. or windbg which output a stream of hardware codes, we can use the hardware code to find matched part of disassembly lines.
3). we also have one shader replacement tool , to drop and replace part of the elf hardware code, if we have full disassembly line with counter and hardware code, it would be handy where to edit hardware code.

Hope it explains.

It doesn't really. If you already parse this text output, surely you could just derive the offset yourself by counting the number of dwords in comments?

you do can count, however instruction is variant 1/2 dword. To get your target instruction offset, i want to save some brainpower out of this.

Please work on removing this feature from the backend instead. It's long past time to stop handling this in the compiler

There are several shader debugger tools/situation dependent on this feature.
e.g. one line like this "s_andn2_b32 vcc_lo, vcc_lo, 0 ;000974: 8A6A806A"
1). we feed the disassembly count "0x000974" to the shader debugger tool to get this line of code execution ,register input and output.
2).Also there is some other shader dump tool,e.g. umr. or windbg which output a stream of hardware codes, we can use the hardware code to find matched part of disassembly lines.
3). we also have one shader replacement tool , to drop and replace part of the elf hardware code, if we have full disassembly line with counter and hardware code, it would be handy where to edit hardware code.

Hope it explains.

You can disassemble the text section in the tooling. The compiler does not need to provide this at all

@arsenm , okay, i get it. you want remove whole disassembly part from AMDGPUAsmPrinter.cpp?

arsenm resigned from this revision.Sep 30 2022, 7:01 PM

I think this isn't needed anymore

This revision now requires review to proceed.Sep 30 2022, 7:01 PM
Herald added a project: Restricted Project. · View Herald TranscriptSep 30 2022, 7:01 PM
Herald added subscribers: kosarev, foad. · View Herald Transcript