A virtual index of -1u indicates that the subprogram's virtual index is
unrepresentable (for example, when using the relative vtable ABI), so do
not emit a DW_AT_vtable_elem_location attribute for it.
Details
Diff Detail
Event Timeline
lib/IR/DIBuilder.cpp | ||
---|---|---|
698–699 | Is zero not sufficient in this spot (& the other below) - since we still have it conditional on virtuality anyway? | |
test/Assembler/disubprogram.ll | ||
34–53 | What's this test testing? I can't quite see what's new/unique/interesting about it. | |
test/DebugInfo/Generic/virtual-index.ll | ||
47 | Given the verbosity of the IR, we usually put all the CHECK lines up above the IR (& include the C++ source that the IR is derived/generate from for illustrative purposes in a comment above the CHECK lines) |
Duncan wrote:
Judicious use of CHECK-SAME: , ... will let you cherry-pick the interesting fields.
Done.
lib/IR/DIBuilder.cpp | ||
---|---|---|
698–699 | Almost, but the IR writer output is not conditional on virtuality, so for example if a client used DIBuilder::createFunction to create a subprogram the IR writer's output for that subprogram would include a zero virtualIndex. Not a major point, but it does make the IR writer output a little easier to match against. | |
test/Assembler/disubprogram.ll | ||
34–53 | This is testing the changed functionality in the IR writer. | |
test/DebugInfo/Generic/virtual-index.ll | ||
47 | Done |
looks good - one piece of optional feedback (make the IR writer consistent with the output selection)
lib/IR/DIBuilder.cpp | ||
---|---|---|
698–699 | Should we just make the IR writer conditional on virtuality, then? seems oddly inconsistent this way? |
lib/IR/DIBuilder.cpp | ||
---|---|---|
698–699 | I don't have a strong opinion on the matter, but I'd normally favour simplicity in the IR writer. But since the bitcode writer writes out these virtual indices (even for non-virtual functions) in VBR format and -1u has a longer representation than 0, I think that tips the scales in favour of using 0 here and adding the conditional to the IR writer. I'll do that then. |
Is zero not sufficient in this spot (& the other below) - since we still have it conditional on virtuality anyway?