[cfe-dev] -fmodules-ts and codegen options

[David Blaikie via cfe-dev]

Should probably be the default - though I implemented it originally for the
backwards compatible modules, but it seems to work pretty well without many
changes for ModulesTS too.

It looks like from the commit you mentioned in the other thread (
https://www.mail-archive.com/cfe-commits@lists.llvm.org/msg54922.html )
"This is in preparation for permitting -emit-obj to be used on a module
interface unit to produce object code without going via a "full" PCM file"
that the second issue you mention (generating the object directly during
module creation) is in the works - maybe in that Richard's planning to
touch the modules-codegen default?

Richard? Thoughts - I'm happy to pick up a few pieces to work on
independently if that's helpful (like changing the
modules-codegen/debuginfo defaults when modules-ts is enabled)

Speaking of modules-codegen: It seemed to hurt code size* for optimized
builds (because many functions are inlined away during compilation, so
their definitions ) link inputs. Should there, perhaps, be a version of
modules-codegen that only does enough to get correctness for modules? (ie:
only externalize the definitions of external (module-internal and otherwise
non-inline) entities in the module - leave the inline functions to behave
as before).

* the numbers were pretty limited, and specifically only based on google's
internal use of modules, focussed on modularization of protos that have
their own fairly esoteric properties (lots of generated inline functions
that could skew the distribution compared to "most" code)

On Thu, Jun 1, 2017 at 5:31 AM Boris Kolpackov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> I have a couple of questions on Clang's Modules-TS usage/future plans:
>
> Currently I have to pass -fmodules-codegen -fmodules-debuginfo along with
> -fmodules-ts when generation a .pcm file from the module interface unit.
> Are there plans to make this the default? Any reason it is not already so?
>
> Currently the production of .o from the module interface unit requires a
> separate compiler invocation. That is: unit -> .pcm -> .o. While there
> are good reasons to do it this way (e.g., parallelism), are there plans
> to also support the single-invocation mode? This could be faster (and
> easier) for build systems that decided not to split this for whatever
> reasons (which, I believe, most of the existing build systems will do,
> at least initially).
>
> Thanks,
> Boris
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170601/385c50a8/attachment.html>