[PATCH] D28845: Prototype of modules codegen

[David Blaikie via cfe-commits]

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 at 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 at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20170118/b3d3781a/attachment-0001.html>