This commit adds a test for debug info generated when the machine
function splitter pass is enabled. We check that the line numbers for
the hot and cold parts of the split function are what we expect them to
|380 ms||linux > HWAddressSanitizer-x86_64.TestCases::sizes.cpp|
Script: -- : 'RUN: at line 3'; /mnt/disks/ssd0/agent/llvm-project/build/./bin/clang --driver-mode=g++ -m64 -gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -mcmodel=large -mllvm -hwasan-globals -mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 -mllvm -hwasan-instrument-personality-functions /mnt/disks/ssd0/agent/llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp -nostdlib++ -lstdc++ -o /mnt/disks/ssd0/agent/llvm-project/build/projects/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp
|510 ms||windows > LLVM.CodeGen/AMDGPU::ds_read2.ll|
Script: -- : 'RUN: at line 2'; c:\ws\w1\llvm-project\premerge-checks\build\bin\llc.exe -march=amdgcn -mcpu=bonaire -verify-machineinstrs -mattr=+load-store-opt < C:\ws\w1\llvm-project\premerge-checks\llvm\test\CodeGen\AMDGPU\ds_read2.ll | c:\ws\w1\llvm-project\premerge-checks\build\bin\filecheck.exe -enable-var-scope -check-prefixes=GCN,CI C:\ws\w1\llvm-project\premerge-checks\llvm\test\CodeGen\AMDGPU\ds_read2.ll
In addition, I wonder where this is layering issue for the testing. This patch adds llvm-objdump -l which is not common in test/DebugInfo. In fact, there is only one test using -S/--source/-l/--line-numbers, so I wonder whether it is the most appropriate testing approach here.
Perhaps this patch should test .loc instead.
This doesn't sound right - we can run ELF tests on non-ELF platforms. (I assume that's what's trying to be avoided/addressed by this?) Note all the other tests in this directory that don't have such UNSUPPORTED tagging.
If this is a general discussion of "What debug info related things should we test for bb-sections in the LLVM project" it'd be good to get a quick summary of what testing already exists.
But otherwise, broad testing I'd think:
But maybe both of these tests are already checked in/implemented?
I don't think there's much need for Split DWARF-specific testing, as the Split DWARF handling of ranges is fairly orthogonal to where they appear (shouldn't be interesting to Split DWARF that the ranges appear on a DW_TAG_subprogram, I don't think).
Yes the llvm-dwarfdump and the split dwarf testing of DW_AT_ranges is already there: test/DebugInfo/X86/basic-block-sections_1.ll
Could the coverage this new test is adding be added to the existing test? Looks like this new test is intended to cover the line table - which could be added to expanded coverage in the basic-block-sections_1.ll by dumping debug_line as well as debug_info (adding "-debug-line" to those existing dwarfdump commands)
Updates based on review comments.
- Use llvm-dwarfdump --debug-line instead of llvm-objdump -l
- Updated the checks, added line numbers to the source.
- Removed unsupported tag, should no longer be required since we don't use llvm-objdump anymore.
Removed, I think this was failing on windows due to the use of llvm-objdump. I'll keep an eye on the windows bot and double check.
The cold block is the one below, the modulus yields the remainder which is interpreted as true for the if condition.
I think there is value in having a simple test for the line table which many downstream tools rely on. We should add a line table test for basic block sections too.
Generally we'd test all the things related to a feature/new/interesting output in the same place. Sometimes worth splitting into multiple files, but there's some benefits to keeping it all together (can page in the context for one feature area, less test process overhead, etc). Admittedly, the tests aren't especially rigorously laid out by any means.
And I see I got this jumbled up between split-machine-functions and bb-sections. What's the difference between those two features? I /guess/ that split-machine-functions is a specific application of/builds on top of bb-sections?
Yes, split-machine-functions is a specific application of basic block sections. The key difference here is the type of profile consumed to drive the layout decisions (FDO/AFDO vs Propeller). From the perspective of the machine function splitting pass this test ensures that the underlying mechanism, i.e. basic block sections updates debug information correctly. Thus I added an independent test. There is some duplication here and if you feel strongly we can just test the line table in the existing basic block sections. WDYT?
Yeah, seems like it's probably better to test this functionality down at the bb-sections level, since that's the functionality it's really testing/relying on. If several features are built on top of bb-sections, we don't want the fundamental testing to only be done via one of those features (if we then remove that feature - might lose the testing), and makes it clearer what testing covers what functionality/implementation code.
Looks like the debug info functionality being tested isn't specific to split-machine-functions, so I'd generally favor not testing it here and instead testing it with bb-sections. (if there's specific DWARF code/functionality only reachable through split-machine-functions, that should be tested here)