<p dir="ltr">> Also, one of the other possible motivations of using LLD directly from Clang would be to avoid process overhead on operating systems where that is a much more significant part of the compile time cost. We could today actually take the fork out of the Clang driver because the Clang frontend *is* designed in this way. But we would also need LLD to work in this way.</p>
<p dir="ltr">Then go change clang and send a patch for lld once you are done. It will be interested to see if you can measure a single fork in an entire build.</p>
<p dir="ltr">Even better, please finish the new pass manager before working on clang forking cc1.</p>
<p dir="ltr">In any case, I have simply wasted too much time on a thread with someone with no patches on the new elf linker. It is really annoying that you don't put effort into it and seem entitled to dictate its direction.</p>
<p dir="ltr">If you want to kick us out of the llvm project, please start a thread on llvm-dev.</p>
<p dir="ltr">If you want lld to be a library, figure out how to do it without sacrificing lld's productivity,  error reporting and performance (no error_code spaghetti) and write a patch. Just don't expect it to be reviewed while we have actual missing features.</p>
<p dir="ltr">I will go back to implementing the linker.</p>
<p dir="ltr">Rafael</p>