<div dir="ltr"><div>This sounds like a great project to me.</div><div><br></div><div>There is already at least one place in Clang that wishes it could do this: when building with -E -frewrite-imports, we build a source file that embeds sources that can be used to transitively rebuild dependency modules. (The dependency modules are expressed via pragmas.) But we can't faithfully represent the options that were used to build those modules, because there's no way to serialize the options from an arbitrary AST file as text. This matters in particular for an explicit modules build, where the set of flags used to build imported modules may differ from the set of flags used to build the consumer of that module.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 13 May 2020 at 14:40, Reid Kleckner 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Broadly speaking, that sounds great. The cc1 interface is unstable, and we can change it to make the mapping from internal state to command line and back simpler. The driver code would benefit much more from this kind of refactoring, but the driver flag handling is so idiosyncratic that this isn't really feasible.<div><br></div><div>My input on working with tablegen is: try to generate a little C++ code as humanly possible. Please try hard to generate readonly data instead of code. It compiles much more quickly, and usually runs just as quickly.</div><div><br></div><div>Our codebase has a bit of a legacy of table generated code gone wrong, and I want to move away from that where possible. See these (stale) stats on the individual functions that take the longest to compile:</div><div><a href="https://reviews.llvm.org/P8191$95" target="_blank">https://reviews.llvm.org/P8191$95</a> llvm::decodeToMCInst</div><div>They are generated here: <a href="https://github.com/llvm/llvm-project/blob/master/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp#L964" target="_blank">https://github.com/llvm/llvm-project/blob/master/llvm/utils/TableGen/FixedLenDecoderEmitter.cpp#L964</a></div><div>I have tried to optimize the code to compile faster, but so far I've had no luck.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 12, 2020 at 11:07 AM Daniel Grumberg via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>I am a PhD student at the Imperial College London currently contracting for Apple, working with Michael Spencer and Duncan Exon Smith on providing build system support for explicit module builds through clang-scan-deps. As part of clang-scan-deps we need to provide build systems with a dependency graph of the modules needed for a given build, as well as a command line that can build each needed module explicitly. Under the hood, clang-scan-deps uses the implicit module build mechanisms to discover modular dependencies. In this setup when we need to generate a command line to build an explicit module we use the command line associated with the TU that discovered the given module and append to it “-remove-preceeding-explicit-module-build-incompatible-options” followed by the options needed to build the module explicitly. The trouble with this is that the command line we generate for building an explicit module is not deterministic, it depends on which TU discovers the module first. Furthermore, this scheme makes it extremely difficult to remove options that are irrelevant to the compilation of the module. What we really want to do is to be able to generate a cc1 command line from first principles given a CompilerInvocation instance.<br><br>In order to achieve this goal, we need a strategy that allows us to synthesize command line arguments from the various fields of a CompilerInvocation instance. Unfortunately, CompilerInvocation does not currently support this use case. We propose to automate the process of generating a command line by embedding information inside the table-gen option description files. This extra information will define the mapping between a given compiler option and the fields of CompilerInvocation using a mechanism similar to Obj-C’s keypaths. We can then use this to generate code that automatically translates from a given option to the correct value of the associated CompilerInvocation field and back. A patch describing the proposed pattern is available at <a href="https://reviews.llvm.org/D79796" target="_blank">https://reviews.llvm.org/D79796</a>. Of course this scheme can not work for complicated mapping logic but we feel that it can automate generating command line arguments and parsing options for the vast majority of cases, which would significantly reduce the amount of custom code inside CompilerInvocation. To make sure that developers keep the mappings up to date, we plan to add an assertion at the end of CompilerInvocation::CreateFromArgs that checks that we can roundtrip back the CompilerInvocation through CompilerInvocation::GenerateCC1CommandLine. This should flag failures in debug builds which would make developers aware of the need to keep the mappings up to date without adding additional runtime overhead to clang.<br><br>Thanks for reading and looking forward to everyone’s comments!<br><br>Daniel Grumberg</div>_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>
_______________________________________________<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="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div></div>