<div dir="ltr"><br><br><div class="gmail_quote"><div dir="ltr">On Wed, May 10, 2017 at 5:02 AM Boris Kolpackov via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
I am working on C++ modules support in the build2 build system[1]. As<br>
part of that I have tested latest Clang (r302560 from <a href="http://apt.llvm.org" rel="noreferrer" target="_blank">apt.llvm.org</a> to<br>
be more precise) with a barely-realistic example (module interface<br>
unit, module implementation unit, and an importing test; compilation<br>
command lines are in 'cmd'):<br>
<br>
<a href="http://codesynthesis.com/~boris/tmp/libhello-clang.tar.gz" rel="noreferrer" target="_blank">http://codesynthesis.com/~boris/tmp/libhello-clang.tar.gz</a><br>
<br>
Here are some notes/issues:<br>
<br>
1. When compiling the module implementation unit, -fprebuilt-module-path<br>
does not work. Instead one has to use -fmodule-file.<br>
<br>
The failure mode is also interesting: there is no diagnostics about<br>
the module not being found but rather about undeclared module entities.<br>
<br>
2. I believe you are aware of this: if a non-inline function is defined<br>
in a module interface unit, things end up badly (duplicate symbols).<br>
<br>
If the plan is to also generate an object file as part of module<br>
interface compilation (the way both VC and GCC currently do it),<br>
then consider supporting separate compilation mode for these two.<br>
The reason is this: the .pcm file has to be generated before any<br>
(a) module importing or (b) module implementation units can be<br>
compiled. So waiting for the .o file to be produced will hinder<br>
parallelism.<br></blockquote><div><br>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.<br><br>I implemented it with the "legacy modules" scenario in mind, but I believe it also works for TS modules, probably.<br><br>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.<br><br>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 :)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
3. When compiling a test that imports a module using -fprebuilt-module-path<br>
a bogus warning is issued:<br>
<br>
clang: warning: argument unused during compilation: '-fprebuilt-module-path=.' [-Wunused-command-line-argument]<br>
<br>
[1] <a href="https://build2.org" rel="noreferrer" target="_blank">https://build2.org</a><br>
<br>
Thanks,<br>
Boris<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>