ckandeler wrote: > 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?
I notice that there are four fields in the Symbol struct that are only relevant for symbols indexed for completion. Presumably these would be candidates for such an extension block? 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
