<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2015-10-13 8:52 GMT+06:00 Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">On Mon, Oct 12, 2015 at 12:13 PM, Richard Smith 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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Oct 12, 2015 at 11:33 AM, Serge Pavlov 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"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Now building a module involves creation of intermediate source streams that includes/imports each header composing the  module. This source stream is then parsed as if it were a source file. So to build a module several transformations must be done:</div><div>- Module map is parsed to produce module objects(clang::Module),</div><div>- Module objects are used to build source stream (llvm::MemoryBuffer), which contains include directives,</div><div>- The source stream is parsed to produce module content.</div><div><br></div><div>The build process could be simpler, if instead of text source stream we prepared a sequence of annotation tokens, annot_module_begin, annot_module_end and some new token, say annot_module_header, which represented a header of a module. It would be something like pretokenized header but without a counterpart in file system.</div><div><br></div><div>Such redesign would help in solving performance degradation reported in PR24667 ([Regression] Quadratic module build time due to Preprocessor::LeaveSubmodule). The reason of the problem is leaving module after each header, even if the next header is of the same module.</div></div></blockquote><div><br></div></span><div>We generally recommend that each header goes in its own submodule, so optimizing for this case doesn't address the problem for a lot of cases.</div></div></div></div></blockquote></span></div></div></div></blockquote><div><br></div><div>These are different use cases and there is nothing bad if the problem will be solved with different means. If a user follow this recommendation and puts each header into a separate module, he won't suffer from the tokenized form of the intermediate input stream. If the user chooses to put many headers into one module, this change can solve the problem. The cited PR refers to just the latter case.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class=""><div><br></div></span><div>The "one huge submodule" approach with no local visibility is actually very useful to have because it (for better or for worse) is very close to the semantics of PCH (which are very simple). This makes it a nice incremental step away from PCH and very easy to understand.</div><div><br></div><div><div>Also, I think "we generally recommend" is a bit strong considering that this isn't documented anywhere to my knowledge. In fact, the documentation I've written internally for my customers recommends the exact opposite for the reason described above.</div></div><span class="HOEnZb"><font color="#888888"><div><br></div></font></span></div></div></div></blockquote><div><br></div><div>This very convenient for users. Usually it is much simpler to write something like #include "clang.h" instead of listing dozen of includes. When API is distributed by many headers, a user must determine first where the necessary piece is declared. In pre-module era splitting API was unavoidable evil, as it reduced compile time. With modules we can enable more convenient solutions.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div></div><div>-- Sean Silva</div></font></span><span class=""><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"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span><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"><div dir="ltr"><div>Leaving module after the last header would be a solution but it is problematic to reveal if the header just parsed is the last one, - there is no such thing as look ahead of the next include directive. Using tokenized input would mark module ends easily.</div></div></blockquote><div><br></div></span><div>I have a different approach in mind for that case: namely, to produce a separate submodule state for distinct submodules even when not in local visibility mode, and lazily populate its Macros map when identifiers are queried. That way, the performance is linear in the number of macros the submodule actually defines or uses, not in the total number defined or used by the top-level module.</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"><span><div dir="ltr"><div>Is there any reason why textual form of the intermediate source stream should be kept? Does implementing tokenized form of it make sense?</div><div><br></div><div><div>Thanks,<br>--Serge<br></div></div>
</div>
<br></span>_______________________________________________<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>
<br></blockquote></div><br></div></div>
<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>
<br></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>