vsapsai added a comment. Looks like in `METHOD_POOL` we don't need the transitive closure for performance reasons. And we are kinda trying to store only data the module owns
> // Only write this selector if it's not in an existing AST or something > // changed. But even if a single method is in the module we are building, we'd serialize entire list of methods for this selector. I've tried a proof of concept https://reviews.llvm.org/D110123 to see what happens if we are more aggressive with skipping methods coming from other modules. It's not entirely correct as we are missing some transitive methods and I have doubts it is the best implementation. But for me it cuts down the compilation time of the synthetic test case and we aren't dealing with any duplicates, so that seems like a viable approach. In bad news this change doesn't fail any tests, so looks like this area isn't sufficiently well tested. What folks are thinking about writing less in `METHOD_POOL`? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D109632/new/ https://reviews.llvm.org/D109632 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
