Added documentation about DW_TAG_immutable_type too.
|590 ms||x64 debian > XRay-x86_64-linux.TestCases/Posix::basic-filtering.cpp|
Script: -- : 'RUN: at line 4'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -fxray-instrument -m64 -std=c++11 /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/xray/TestCases/Posix/basic-filtering.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/xray/X86_64LinuxConfig/TestCases/Posix/Output/basic-filtering.cpp.tmp -g
Typically I've done "support" for a tag or other DWARF feature in several phases, each usually (not necessarily) with its own patch. Each phase builds on the previous one, which is the project's preferred incremental-development model.
- First, do enough so that llvm-dwarfdump can correctly handle an object file with a DW_TAG_immutable_type in it; this generally means tweaking lib/DebugInfo/DWARF a little bit, as I see you have done. The test can be an assembler file with the raw bytes listed; there are many examples of this.
- Next, make it so textual IR can describe an immutable type, which can be emitted into an object file. The IR part might involve round-tripping through textual and bitcode formats to show that all works. For the object-file part you use llvm-dwarfdump, because your previous work verified that llvm-dwarfdump handles the tag correctly.
- Next, if you need to fiddle with DIBuilder to get the IR API to handle immutable types, you do that, probably with a unittest (not a Clang test, because LLVM has other frontend clients and LLVM testing should not depend on any of them).
- Finally, if this is a C/C++ language feature, you plumb it into Clang to emit the tag when appropriate, with a test that uses -emit-llvm and verify that the IR comes out right. I'm not aware that "immutable" is a C/C++ feature, but I find it hard to keep up with the C++ standard.
If the whole thing is trivial enough--which it might be, because this is a type qualifier like many others--you can do multiple phases in one patch, but we still want to see that each step has the proper testing.
I did separate patches since they are independent of each other. As a new LLVM contributor, there are some things I miss, and I appreciate this input!
One of the rationales to do this was: since I've seen separate people working in LLVM core and LLDB I decided to separate documentation, and those pieces apart. I thought this could be beneficial for separate reviewers to analyze the change "in the lldb part", "in the llvm core part" and not as a whole. Plus, I noticed that different people get pinged depending on the patch and I assume it has something to do with the patch prefix.
Usually (not always, but usually) related patches are split by subproject. So, lldb changes go in one patch, llvm in another patch, clang in another patch. Exceptions occur when patches are very closely related or actually interdependent. I don't think adding immutable_type falls into that category. So, please keep the lldb and llvm patches separate.
Code looks quite reasonable; the test needs a little cleanup.
|3 ↗||(On Diff #396687)|
I believe you can remove the REQUIRES, explicit triple on the llc command, and the target triple IR clause, to allow this to work generically; there doesn't really seem to be anything X86-specific here. You'll want to use %llc_dwarf instead of llc as the command, which will insert an appropriate triple for hosts that don't implicitly use DWARF. See other examples of this in the same test directory.
|9 ↗||(On Diff #396687)|
This should be just CHECK: not CHECK-LABEL:.