-fmodules-ts and codegen options

Clang Frontend
1

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

2

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)
3

Hi David,

David Blaikie <dblaikie@gmail.com> writes:

"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 [...]

That sounds great. Just to make sure I am clear about what I am hoping for:

The ability to generate both .pcm and .o with a single compiler invocation
and being able to specify the output file names for both. Currently both
use the -o option (in separate invocations).

Thanks,
Boris

4

Yes, we'll provide support for that at some point. We've been discussing
the command-line interface with the people working on the Modules TS
implementation in GCC, and aim to provide a consistent command-line syntax
across both compilers, including a mechanism to produce the .o file and the
.pcm file from a single compiler invocation.