labath wrote:
> I guess what I was proposing was more about deleting code than adding it. We
> must always have at most _one_ index, but we have a lot of code allowing for
> the situation of two indices (manual & {apple, dwarf}).
Okay. I think I understand now what you meant -- which was to have each compile
unit to store some sort of a reference to "its" index (is that right)? If
that's the case, then I don't think that could work. While it's true that every
CU is covered by exactly one index, a single index can (and usually does) cover
more than one CU, and there isn't a good way to partition it along CU
boundaries. The apple indexes such shove everything into a single table, which
is indexed by name (a hash of it). There's no way to efficiently query only for
entries belonging to a single unit. With per-CU debug_names indexes, we could
do that, but we also have multi-cu indexes, where we'd have the same problem.
(For manual indexes, we could do what we want, but we'd need to be careful to
not regress performance, as we currently get a large speed boost from the
paralelization of the indexing step).
On top of that, this isn't really a good match for the way indexes are used.
When querying the index, we usually don't know which CU we want to look at (if
we did, we may not even need the index). We just have a name, and we want the
CU (and the DIE within that CU) which defines that name. Even if we created
something like this, it would mean that each query would basically become a
loop over all CUs to see which one contains the thing we're looking for.
https://github.com/llvm/llvm-project/pull/102123
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
