<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Oct 23, 2015 at 10:28 AM, Louis Brandy via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi cfe-dev,<br>
<br>
My name is Louis Brandy and I work at Facebook. I’ve begun working on<br>
getting clang modules setup in our C++ codebase. Mostly the purpose of<br>
this email is just to introduce myself and let people know what we’re<br>
doing and our motivation, but I’ve also brought a handful of newbie<br>
questions. I’ve gotten the basic integrations into the build system and<br>
have some core projects building modularly. To get this far, I hacked<br>
together a highly unprincipled set of module maps for glibc, libstdc++.<br>
I’m at the point, now, where I need “real” module maps for our std/system<br>
headers.<br>
<br>
First, is there any prior art re: glibc and libstdc++ module maps? I don’t<br>
want to repeat any work that’s already been done, and my google-fu failed.<br></blockquote><div><br></div><div>Richard, I remember in the past we talked and you sent me your glibc module map and small patches. Any chance you could attach your latest ones here? Looking back in my email, you said that you didn't have a libstdc++ module map. Is that still the case?</div><div><br></div><div>Louis, I'm going to be setting up a LLVM/Clang buildbot (running linux) that uses modules for building LLVM itself next week or so, so I'll definitely keep you up to date.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Second, I’m interested in the workflow of actually incrementally adding<br>
module maps to a large codebase. I do understand the need to start at the<br>
bottom but I’m worried about proper coverage, and then prioritizing what<br>
to do next. In particular, I find myself really wanting a “summary” of<br>
what #includes did and did not magically become imports so I can use that<br>
to make sure 1) I’ve not missed anything “below” and 2) to prioritize what<br>
to do next (by e.g. aggregating over a build the most textually included<br>
headers).</blockquote><div><br></div><div>When I first went to investigate how much time is spent in which header, I placed some DTrace probes inside of clang and aggregated the time spent textually within a file across compiler invocations. See the thread "Some DTrace probes for measuring per-file time." (<a href="http://lists.llvm.org/pipermail/cfe-dev/2015-April/042334.html">http://lists.llvm.org/pipermail/cfe-dev/2015-April/042334.html</a>)</div><div>The raw data that comes out of that DTrace script is a list of pairs {"/path/to/file", total time spent in this file across all compiler invocations}.</div><div>I then looked at the data in this Mathematica notebook: <a href="https://drive.google.com/file/d/0B8v10qJ6EXRxTWpMTTBnaERQaVU/view?usp=sharing">https://drive.google.com/file/d/0B8v10qJ6EXRxTWpMTTBnaERQaVU/view?usp=sharing</a></div><div><br></div><div>Note that in that notebook (one of many) I removed the time spent after parsing (basically, codegen time), so the pie chart at the end is a bit deceptive.</div><div>I've attached two pie charts that include the time spent after parsing.</div><div>The first is a debug build (low optimization). The latter is a a release build (for a release build, a much larger fraction of time is spent in codegen).</div><div><br></div><div>If you don't have DTrace available so that you can directly measure the time, you can probably get a decent idea based on the inclusion counts. One easy way to do this is to tally up files mentioned by the -H option whose output you can massage. There is also '.d' files, but I forget exactly what we emit into them (we may emit header file names even if we didn't textually touch the header, but only loaded its module).</div><div><br></div><div>Note that for measuring the time, you need to use a timestamp that is virtualized CPU time. If you use real time then you will spuriously count IO latency and other stuff, which will give wrong results (e.g. the total sum of time will appear much larger than is possible).</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> I don’t think such a diagnostic/remark exists? I’ve not looked<br>
too deeply, yet, at clang-modularize, so perhaps my answers lie over<br>
there?<br></blockquote><div><br></div><div>We have -Wauto-import which is sort of the opposite of this. Adding the reverse warning "warn me when you included a header but didn't know about it from a module map" could probably be done.</div><div><br></div><div><div>-- Sean Silva</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
On a final note, it’s been remarkably easy to get modules up and running<br>
so kudos to everyone who’s gotten it this far.<br>
<br>
-Louis<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">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><br></div></div>