Oh, remembered I had one other question/idea: Tangentially related to the question about non-inline functions in headers:
Currently .pcm files have the 'interesting decls' list. Are there any interesting decls once modules codegen is in use? It seems mostly the interesting decls are things like non-inline functions (& perhaps global variables - I haven't got to those yet & I think I remember you mentioning they might be trickier due to ordering requirements?). If not, we could perhaps repurpose the interesting decls list as the modular codegen decls list - but then we'd need a flag to say "actually, we're doing modular codegen for this module". So perhaps having it as a separate list provides the same functionality & is clearer anyway. On Tue, Jan 17, 2017 at 8:08 PM David Blaikie via Phabricator via cfe-commits <cfe-commits@lists.llvm.org> wrote: > dblaikie created this revision. > > First pass at generating weak definitions of inline functions from module > files > (& currently skipping definitions of those functions in uses) > > I've done some manual testing (haven't delved into the preferred testing > strategy for modules). Seems to work for simplest cases, including > transitive > modules. > > Also doesn't have an actual flag plumbed through, yet. I can submit that > ahead > of this in a separate patch (open to ideas, etc). Is there a goal for how > explicit modules should be used via the driver (rather than cc1)? Otherwise > this would be a cc1 option to match. > > One quandry: What to do with non-inline definitions in headers? Currently > this > prototype moves their emission (while keeping their linkage) to the module > object. This would remove ODR violations and actually make it 'correct' to > define a non-inline function in a header, which may or may not be > desirable. It > could be kept in all the users as it is today. > > I'm sure I don't know nearly enough about linkage and about how linkage is > handled in Clang & LLVM. So I'm certainly open to ideas about how this > implementation isn't ideal or correct - or the myriad of interesting > linkage > cases I should test/consider. > > Perhaps we could chat about this in person/over the shoulder if a faster > iteration would be worthwhile. > > > https://reviews.llvm.org/D28845 > > Files: > include/clang/AST/ASTContext.h > include/clang/AST/ExternalASTSource.h > include/clang/Basic/LangOptions.def > include/clang/Basic/Module.h > include/clang/Serialization/ASTBitCodes.h > include/clang/Serialization/ASTReader.h > include/clang/Serialization/ASTWriter.h > lib/AST/ASTContext.cpp > lib/AST/ExternalASTSource.cpp > lib/Basic/Module.cpp > lib/CodeGen/CodeGenModule.cpp > lib/Lex/ModuleMap.cpp > lib/Serialization/ASTReader.cpp > lib/Serialization/ASTWriter.cpp > lib/Serialization/ASTWriterDecl.cpp > > _______________________________________________ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >
_______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
