nridge added a comment. In D59407#1456394 <https://reviews.llvm.org/D59407#1456394>, @sammccall wrote:
> One thing that strikes me here is that this case is very similar to our > existing Ref data - it's basically a subset, but with a symbolid payload > instead of location. We could consider just adding the SymbolID to Refs - > it'd blow up the size of that by 50%, but we may not do much better with some > other representation, and it would avoid adding any new complexity. Note that this was considered and rejected earlier (see here <https://reviews.llvm.org/D58880#1418840> and here <https://reviews.llvm.org/D58880#1418840>), though that discussion did not consider denser relations like callgraph. Given the additional information and perspectives from the conversation here, I have two suggestions for potential ways forward: **Approach 1: Add SymbolID to Refs** - This would be initially wasteful when only subtypes use it, but if we then build callgraph on top of it as well it will become significantly less wasteful. - This has the benefit that we don't have duplicate information for find-references and callgraph (they both use Refs). - This approach probably adds the least amount of complexity overall. **Approach 2: Add a RelationSlab storing (subject, predicate, object) triples, intended for sparse relations** - This would allow us to implement features that require sparse relations, such as subtypes and overrides, without any significant increase to index size. - If we later want to add dense relations like callgraph, we'd use a different mechanism for them (possibly by adding SymbolID to Refs as in approach 1). - If we do end up adding SymbolID to Refs for callgraph, and want to start using that for sparse relations too, we can rip out RelationSlab. - This also adds relatively little complexity, though slightly more than approach 1, and we are throwing away some code if we end up adding SymbolID to Refs eventually. Any thoughts on which of the approaches to take, or something else altogether? It would be good to have confidence that the chosen approach will pass code review before I spend time implementing it :) Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D59407/new/ https://reviews.llvm.org/D59407 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
