[cfe-dev] [Modules TS] feedback

[David Blaikie via cfe-dev]

On Wed, May 10, 2017 at 5:02 AM Boris Kolpackov via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi,
>
> I am working on C++ modules support in the build2 build system[1]. As
> part of that I have tested latest Clang (r302560 from apt.llvm.org to
> be more precise) with a barely-realistic example (module interface
> unit, module implementation unit, and an importing test; compilation
> command lines are in 'cmd'):
>
> http://codesynthesis.com/~boris/tmp/libhello-clang.tar.gz
>
> Here are some notes/issues:
>
> 1. When compiling the module implementation unit, -fprebuilt-module-path
>    does not work. Instead one has to use -fmodule-file.
>
>    The failure mode is also interesting: there is no diagnostics about
>    the module not being found but rather about undeclared module entities.
>
> 2. I believe you are aware of this: if a non-inline function is defined
>    in a module interface unit, things end up badly (duplicate symbols).
>
>    If the plan is to also generate an object file as part of module
>    interface compilation (the way both VC and GCC currently do it),
>    then consider supporting separate compilation mode for these two.
>    The reason is this: the .pcm file has to be generated before any
>    (a) module importing or (b) module implementation units can be
>    compiled. So waiting for the .o file to be produced will hinder
>    parallelism.
>

Agreed, and actually, Clang already supports generating object files for
modules and the only way it supports it right now is as you've suggested -
as a separate build step that takes the pcm file and generates an object,
for the reasons you've mentioned.

I implemented it with the "legacy modules" scenario in mind, but I believe
it also works for TS modules, probably.

Passing -fmodules-codegen and -fmodules-debuginfo (I think I'm remembering
the spelling right) to the step that creates the pcm file will establish
the right conditions, then passing that pcm file to clang again -c, should
generate the required object file.

This hasn't been widely deployed, but I have tested it internally on large
programs using explicit legacy modules and produced objects that
successfully link and are substantially (~10% less .text in input objects,
maybe 30% less debug info) smaller (at least at -O0 - higher optimization
levels make the object code part less useful/outright harmful to object
size (perhaps a lesser mode could be implemented for TS modules
correctness, where only non-inline functions are tied to the modular
object) but the debug info remains useful). Let me know if you want/need
further details and I'd be glad to hear about any results/comments/patches
you have to the functionality :)


>
> 3. When compiling a test that imports a module using -fprebuilt-module-path
>    a bogus warning is issued:
>
>    clang: warning: argument unused during compilation:
> '-fprebuilt-module-path=.' [-Wunused-command-line-argument]
>
> [1] https://build2.org
>
> 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/20170510/4e9a561f/attachment.html>