HighCommander4 wrote:
Two quick thoughts, based on reading the discussion so far and a cursory glance
at the patch:
1. Do we need to store a decl/def range in both `Symbol::Definition` and
`Symbol::CanonicalDeclaration`? We could cut the memory usage overhead of the
patch in half by only having it in one of them. (@kadircet would that change
your analysis of the tradeoffs at all?) If we only need one decl/def range per
symbol, but sometimes it's at the definition and sometimes at the declaration,
we could have a top-level field in `Symbol` store it.
2. A more general musing: it would be nice to have a mechanism for storing
additional information for a subset of symbols, without incurring the overhead
of increasing the representation size of **every** symbol. If we had such a
mechanism, we could cut down the overhead of this patch further, by e.g. only
storing the decl/def range for functions rather than all symbol types.
* Perhaps this could take the form of a pointer field in `Symbol` which for
a subset of symbols points to additional data stored in the symbol slab? That
would, in and of itself, not reduce the memory footprint compared to (1), since
the pointer would take up 8 bytes, the same as a decl/def range stored inline.
However, we've had use cases like this come up before. (An example that comes
to mind is storing all definitions for symbols with multiple definitions; see
[this
comment](https://github.com/clangd/clangd/issues/1673#issuecomment-1594211998)
and the next few.) So maybe it would be forward-looking to pay the cost for
that pointer once, and unlock the ability to store various extra data in the
future?
https://github.com/llvm/llvm-project/pull/118102
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
