This is an archive of the discontinued LLVM Phabricator instance.

[Debugify] Accumulate the number of variables in debugify metadata
ClosedPublic

Authored by asi-sc on Oct 28 2022, 6:55 AM.

Details

Summary

When a module contains more than one function, we should update debugify metadata
by increasing the number of variables in the function rather than overwritting it.

Diff Detail

Event Timeline

asi-sc created this revision.Oct 28 2022, 6:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2022, 6:55 AM
Herald added a subscriber: hiraditya. · View Herald Transcript
asi-sc requested review of this revision.Oct 28 2022, 6:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 28 2022, 6:55 AM
asi-sc planned changes to this revision.Oct 28 2022, 7:24 AM
asi-sc updated this revision to Diff 471549.Oct 28 2022, 7:41 AM

Erase old debugify metadata before revisiting the module

A gentle ping

could you add a small test case here ?

llvm/lib/CodeGen/MachineDebugify.cpp
165

LGTM here

176

Here is runOnModule not runOnFunction, so I think here should only has 1 "llvm.mir.debugify".
I think the process should be "run 1 time debugfy for a module" --> optimizations--> "debugfy check" --> "clear the debugify info before next debugify cycle"
Sorry for the code is a little long time for me.

asi-sc updated this revision to Diff 476835.Nov 21 2022, 2:52 AM

Add a test, address review comments

asi-sc added inline comments.Nov 21 2022, 2:57 AM
llvm/lib/CodeGen/MachineDebugify.cpp
176

Yeah, I did it a little wrong. So, the root cause is that we don't strip llvm.mir.debugify metadata. In this patch I suggest just checking that we do not forget to remove the old metadata when re-running the pass. And I'll create a fix to stripDebugifyMetadata to strip not only llvm.debugify but llvm.mir.debugify as well.

xiangzhangllvm added inline comments.Nov 21 2022, 5:22 PM
llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
1

It is strange we check nothing, so how to judge this test is pass or not ?

asi-sc added inline comments.Nov 22 2022, 12:07 AM
llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
1

We do check exit code. As you can see, we remove "xfail" in this patch. So, we had an assertion that is fixed by this patch:

asi@asi:~/dev/sources/llvm-project-mainstream/build-release$ bin/llvm-lit ../llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir  -a
-- Testing: 1 tests, 1 workers --
XFAIL: LLVM :: CodeGen/Generic/MIRDebugify/multifunction-module.mir (1 of 1)
Script:
--
: 'RUN: at line 1';   /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc -run-pass=mir-debugify,mir-check-debugify /home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
--
Exit Code: 134

Command Output (stderr):
--
+ : 'RUN: at line 1'
+ /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc -run-pass=mir-debugify,mir-check-debugify /home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
llc: /home/asi/dev/sources/llvm-project-mainstream/llvm/lib/CodeGen/MachineCheckDebugify.cpp:84: virtual bool {anonymous}::CheckDebugMachineModule::runOnModule(llvm::Module&): Assertion `Var <= NumVars && "Unexpected name for DILocalVariable"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc -run-pass=mir-debugify,mir-check-debugify /home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
1.      Running pass 'Machine Check Debug Module' on module '/home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir'.
 #0 0x00005586602463c5 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x0000558660243ab4 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007f74926dc520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x00007f7492730a7c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #4 0x00007f7492730a7c __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #5 0x00007f7492730a7c pthread_kill ./nptl/pthread_kill.c:89:10
 #6 0x00007f74926dc476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #7 0x00007f74926c27f3 abort ./stdlib/abort.c:81:7
 #8 0x00007f74926c271b _nl_load_domain ./intl/loadmsgcat.c:1177:9
 #9 0x00007f74926d3e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#10 0x000055865f25babf (anonymous namespace)::CheckDebugMachineModule::runOnModule(llvm::Module&) MachineCheckDebugify.cpp:0:0
#11 0x000055865f7e4415 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x5b83415)
#12 0x000055865d3de27f compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#13 0x000055865d3df116 main (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x377e116)
#14 0x00007f74926c3d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#15 0x00007f74926c3e40 call_init ./csu/../csu/libc-start.c:128:20
#16 0x00007f74926c3e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#17 0x000055865d3d1a25 _start (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x3770a25)
/home/asi/dev/sources/llvm-project-mainstream/build-release/test/CodeGen/Generic/MIRDebugify/Output/multifunction-module.mir.script: line 1: 11064 Aborted                 (core dumped) /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc -run-pass=mir-debugify,mir-check-debugify /home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir

I can precommit the test if you want to run it.
As for checks, I don't think we must once again check debugify functionality as we already have a few tests targeted it. It should be enough to verify that llc finishes correctly.

llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
1

Does this is standard way to check test ? I didn't see this way before.
Not sure the assert is allowed/expected in auto testing tools.

asi-sc added inline comments.Nov 22 2022, 1:20 AM
llvm/test/CodeGen/Generic/MIRDebugify/multifunction-module.mir
1

Not sure the assert is allowed/expected in auto testing tools.

XFAIL can we used for this purpose. You might want to check test/CodeGen/AMDGPU/infinite-loop-evergreen.ll as an example:

asi@asi:~/dev/sources/llvm-project-mainstream/build-release$ bin/llvm-lit ../llvm/test/CodeGen/AMDGPU/infinite-loop-evergreen.ll -a
-- Testing: 1 tests, 1 workers --
XFAIL: LLVM :: CodeGen/AMDGPU/infinite-loop-evergreen.ll (1 of 1)
Script:
--
: 'RUN: at line 3';   /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc -march=r600 -mcpu=cypress < /home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/AMDGPU/infinite-loop-evergreen.ll | /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/FileCheck /home/asi/dev/sources/llvm-project-mainstream/llvm/test/CodeGen/AMDGPU/infinite-loop-evergreen.ll
--
Exit Code: 2

Command Output (stderr):
--
error: no check strings found with prefix 'CHECK:'
error: Extra register needed to handle CFG
llc: /home/asi/dev/sources/llvm-project-mainstream/llvm/lib/Target/AMDGPU/R600MachineCFGStructurizer.cpp:1010: int {anonymous}::R600MachineCFGStructurizer::mergeLoop(llvm::MachineLoop*): Assertion `!ExitingMBBs.empty() && "Infinite Loop not supported"' failed.
PLEASE submit a bug report to https://github.com/llvm/llvm-project/issues/ and include the crash backtrace.
Stack dump:
0.      Program arguments: /home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc -march=r600 -mcpu=cypress
1.      Running pass 'Function Pass Manager' on module '<stdin>'.
2.      Running pass 'AMDGPU Control Flow Graph structurizer Pass' on function '@inf_loop_irreducible_cfg'
 #0 0x000055da349f63c5 PrintStackTraceSignalHandler(void*) Signals.cpp:0:0
 #1 0x000055da349f3ab4 SignalHandler(int) Signals.cpp:0:0
 #2 0x00007fb1543cc520 (/lib/x86_64-linux-gnu/libc.so.6+0x42520)
 #3 0x00007fb154420a7c __pthread_kill_implementation ./nptl/pthread_kill.c:44:76
 #4 0x00007fb154420a7c __pthread_kill_internal ./nptl/pthread_kill.c:78:10
 #5 0x00007fb154420a7c pthread_kill ./nptl/pthread_kill.c:89:10
 #6 0x00007fb1543cc476 gsignal ./signal/../sysdeps/posix/raise.c:27:6
 #7 0x00007fb1543b27f3 abort ./stdlib/abort.c:81:7
 #8 0x00007fb1543b271b _nl_load_domain ./intl/loadmsgcat.c:1177:9
 #9 0x00007fb1543c3e96 (/lib/x86_64-linux-gnu/libc.so.6+0x39e96)
#10 0x000055da3222c3bf (anonymous namespace)::R600MachineCFGStructurizer::loopendPatternMatch() R600MachineCFGStructurizer.cpp:0:0
#11 0x000055da3222f524 (anonymous namespace)::R600MachineCFGStructurizer::runOnMachineFunction(llvm::MachineFunction&) R600MachineCFGStructurizer.cpp:0:0
#12 0x000055da33a39595 llvm::MachineFunctionPass::runOnFunction(llvm::Function&) (.part.0) MachineFunctionPass.cpp:0:0
#13 0x000055da33f938e3 llvm::FPPassManager::runOnFunction(llvm::Function&) (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x5b828e3)
#14 0x000055da33f93b19 llvm::FPPassManager::runOnModule(llvm::Module&) (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x5b82b19)
#15 0x000055da33f94415 llvm::legacy::PassManagerImpl::run(llvm::Module&) (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x5b83415)
#16 0x000055da31b8e27f compileModule(char**, llvm::LLVMContext&) llc.cpp:0:0
#17 0x000055da31b8f116 main (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x377e116)
#18 0x00007fb1543b3d90 __libc_start_call_main ./csu/../sysdeps/nptl/libc_start_call_main.h:58:16
#19 0x00007fb1543b3e40 call_init ./csu/../csu/libc-start.c:128:20
#20 0x00007fb1543b3e40 __libc_start_main ./csu/../csu/libc-start.c:379:5
#21 0x000055da31b81a25 _start (/home/asi/dev/sources/llvm-project-mainstream/build-release/bin/llc+0x3770a25)

Does this is standard way to check test ? I didn't see this way before.

It's not as common as FileCheck, because usually we'd like to verify exact match with some pattern. However, sometimes it's OK to check just successful execution, e.g. CodeGen/AMDGPU/write-register-vgpr-into-sgpr.ll or CodeGen/X86/pr38038.ll. In general, I was able to grep ~1500 tests that check llc return code.

Yes, We use XFAIL to mark a test as an expected failure. An XFAIL test will be successful if its execution fails, and will be a failure if its execution succeeds.
But now we are not expected failure. it is strange to test a test case by check nothing (only expect it not go to assert). I am not much sure about it.
@dsanders any suggestions ?

Yes, We use XFAIL to mark a test as an expected failure. An XFAIL test will be successful if its execution fails, and will be a failure if its execution succeeds.
But now we are not expected failure. it is strange to test a test case by check nothing (only expect it not go to assert). I am not much sure about it.
@dsanders any suggestions ?

Let me auto-generate checks then? I don't think we really need them here, however, I'm not strongly against. If it's the only problem, it does not worth such a long discussion :)

Auto gen is unneccesary.
Try use CHECK-NOT: "assert message" ?

asi-sc updated this revision to Diff 477422.Nov 23 2022, 2:01 AM

Rebased and added test checks to make forward progress on the review.

xiangzhangllvm accepted this revision.Nov 23 2022, 4:46 PM

LGTM, thanks for your contribution!

This revision is now accepted and ready to land.Nov 23 2022, 4:46 PM
This revision was landed with ongoing or failed builds.Nov 24 2022, 7:50 AM
This revision was automatically updated to reflect the committed changes.

I had to revert the change as I mistakenly forgot to strip the test from various x86 info such as regs, etc. So, almost all targets failed to run the test correctly. I'll update it soon.

asi-sc reopened this revision.Nov 24 2022, 8:41 AM
This revision is now accepted and ready to land.Nov 24 2022, 8:41 AM
asi-sc updated this revision to Diff 477811.Nov 24 2022, 8:41 AM

Fix the test