[PATCH] D28845: Prototype of modules codegen

David Blaikie via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Sat Jan 28 23:47:05 PST 2017


dblaikie marked 6 inline comments as done.
dblaikie added a comment.

Addressed CR feedback



================
Comment at: lib/AST/ExternalASTSource.cpp:33
+ExternalASTSource::hasExternalDefinitions(unsigned ID) {
+  return EK_ReplyHazy;
+}
----------------
rsmith wrote:
> You should add support for this function to `clang::MultiplexExternalSemaSource` too.
Done - though is there any test coverage I should add? Not sure exactly when/where/how this is used.

Also only made a rough guess at what the right behavior is here. It could be a bit more obvious if I made "hasExternalDefinitions" return Optional<ExtKind> - then when we find an ExternalASTSource that owns the ID (are the IDs unique across the MultiplexExternalSemaSource? I assume they have to be, but thought they'd only be valid within a single Module... guess I'm confused in a few ways - certainly haven't thought about it in great detail) we'd know to stop asking other sources. Probably not worth it unless there's a lot of sources?


================
Comment at: lib/Serialization/ASTWriterDecl.cpp:2215-2219
+  if (isRequiredDecl(D, Context, WritingModule, false))
     EagerlyDeserializedDecls.push_back(ID);
+  else if (Context.getLangOpts().ModularCodegen && WritingModule &&
+           isRequiredDecl(D, Context, true, true))
+    ModularCodegenDecls.push_back(ID);
----------------
rsmith wrote:
> I suspect we'll want to seriously prune back the contents of `EagerlyDeserializedDecls` for the modular codegen case at some point, but we don't need to do that in this change.
Right - I was wondering if we'd end up with anything in EagerlyDeserializedDecls when modular codegen is fully implemented. (if that's the case - we could have only one list, and a 'bit' to say whether it's modular codegen decls or EagerlyDeserializedDecls, if these records/blobs/whatnot are expensive to have two of rather than one - but I don't think that's the case so probably more readable/self-documenting to use two lists as we are)


https://reviews.llvm.org/D28845





More information about the cfe-commits mailing list