[PATCH] D28845: Prototype of modules codegen
David Blaikie via cfe-commits
cfe-commits at lists.llvm.org
Wed Jan 18 09:46:59 PST 2017
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
> (& 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
> Also doesn't have an actual flag plumbed through, yet. I can submit that
> 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
> 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
> cases I should test/consider.
> Perhaps we could chat about this in person/over the shoulder if a faster
> iteration would be worthwhile.
> cfe-commits mailing list
> cfe-commits at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cfe-commits