[llvm] [LLVM][DebugInfo]Allow ExtraData field to be a node reference (PR #165023)
Alexander Yermolovich via llvm-commits
llvm-commits at lists.llvm.org
Thu Oct 30 07:16:08 PDT 2025
ayermolo wrote:
> I feel like I'm being a bit of a stick in the mud here possibly unnecessarily - I'd be perfectly happy if someone else wants to approve this as is.
>
> It feels like an odd change to me because although yes it is asserting, which isn't very user-friendly, it seems like accepting non-constant data is not intended. Without knowing the tool at all, naively, it sounds like this would ideally be solved in llvmlite (i.e., emit/consume the metadata constants) rather than in LLVM. Taking this to an extreme, we wouldn't want to accept metadata tuples of constants _everywhere_ that metadata constants are accepted.
>
> That said, this area does seem poorly specified. The langref only briefly mentions the extraData field and the verifier doesn't complain. I think in an ideal world the verifier would have complained about the tuple extraData, rather than hitting an assert later.
>
> I think I'd feel slightly better about it if verifier checks could be added?
Yes you are right, this area of specification could use a bit more clarity.
I see your point on verifier.
I think in this particular case the intent of this diff is to enable numba-cuda debugging for various versions of llvm-lite. So in aggregate it improves the stability of compilation flow.
I believe the issue is only in DwarfUnit.cpp:
```
} else if (Tag == dwarf::DW_TAG_variant_part) {
// When emitting a variant part, wrap each member in
// DW_TAG_variant.
DIE &Variant = createAndAddDIE(dwarf::DW_TAG_variant, Buffer);
if (Constant *CI = DDTy->getDiscriminantValue()) {
addDiscriminant(Variant, CI,
DD->isUnsignedDIType(Discriminator->getBaseType()));
}
```
To limit the scope one possibility is
1) to call extractConstantMetadata just in getDiscriminantValue
2) move logic of extractConstantMetadata into that code and use getExtraData()
https://github.com/llvm/llvm-project/pull/165023
More information about the llvm-commits
mailing list