rmaz added a comment. In D109632#3005512 <https://reviews.llvm.org/D109632#3005512>, @vsapsai wrote:
> Thanks for the explanation! I'm still curious to reproduce the problem > locally and have created a test case generator > https://gist.github.com/vsapsai/f9d3603dde95eebd23248da4d7b4f5ec It creates a > chain of .m -> Synthesized9 -> Synthesized8 -> Synthesized7 ->... Does it > represent the structure of the code you are dealing with? The case we have is more like: .m -> A -> long list of partially shared deps -> Foundation -> B -> long list of partially shared deps -> Foundation -> C -> long list of partially shared deps -> Foundation .... * a few hundred So we have a file that imports a lot of modules, in the hundreds. Each of those modules has multiple ObjC interfaces with `-(id)init NS_UNAVAILABLE` and imports Foundation, UIKit and also a large number of libraries that are shared across the top level imports. This will result in A.pcm, B.pcm and C.pcm including hundreds or thousands of init decls that are the same, from system frameworks or whatever modules are shared between the top level imports. IIUC the code currently serializes the entire ObjCMethodList for a module for every declared method, including the methods that are not part of that module. When deserializing we don't descend into module dependencies as the entire method list would already be deserialized, but that doesn't help for modules that aren't directly dependent. Is this right? If so it seems another approach could be to only serialize the methods declared in that module itself, and during deserialization we would have to load the methods from all dependent modules. 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
