Sorry for the late response.
I have spent some time prototyping and investigating the DW_IDX_parent approach to the decl context parent chain (option 3 as discussed in the post). The most significant performance concern arises from the consumer/lldb side, and I’ll explain it in more detail below.
According to the specification, DW_IDX_parent can represent either the parent pool entry index (the “Index of the name table entry for the parent”) or the parent pool entry offset (“This is represented as the offset of the entry relative to the start of the entry pool”). It might be a bit confusing which one to use, but it doesn’t matter for explaining the performance issue.
When a consumer locates a name entry, it needs to traverse the parent chain via DW_IDX_parent to construct the full decl context. For each DW_IDX_parent, it must quickly find two pieces of information: 1. the parent pool entry, and 2. the parent pool entry’s name. Since the second piece lacks a lookup table (the name index is not designed for this kind of reverse lookup), the consumer has to create a mapping table from pool entry to name entry to obtain the name. As some parent pool entries can be nameless (e.g., types inside an anonymous namespace), the consumer has to scan through all pool entries and cross-check with the name entries’ range to build this mapping. The net result is that any potential type match in a name index will require all pool entries in that index to be indexed.
Based on this analysis, it appears that option 2 (using DW_IDX_type_hash) would be a simpler and faster design. Please let me know if this explanation makes sense.