[PATCH] D69825: [Clang][Driver] Re-use the calling process instead of creating a new process for the cc1 invocation

Hans Wennborg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 20 06:23:09 PST 2019


hans added inline comments.


================
Comment at: clang/lib/Driver/Job.cpp:347
+    StringRef DriverExe = llvm::sys::path::stem(D.ClangExecutable);
+    if (CommandExe.equals_lower(DriverExe))
+        CC1Main = Driver::CC1Main;
----------------
aganea wrote:
> hans wrote:
> > Now that we're not calling main() anymore, but cc1 directly -- is this checking still necessary?
> Yes it is - see my other comment just above.
> 
> The driver builds phases that do not always call the cc1 process. Simply stating `clang a.cpp` would invoke `clang -cc1`, then the linker, say `link.exe`. In this later case (invoking `link.exe`), even if we have `Driver::Main` it doesn't mean we should use it. There are a number of other edge cases of the same kind, such as `/fallback` or building cuda files, where a different executable is invoked along the way."
Okay, but couldn't we find a cleaner way of figuring out that the Command is a cc1 invocation? The thing that creates the Command would know.. maybe it could set a flag or something? Or maybe instead of creating a Command it would create something else?


================
Comment at: clang/lib/Driver/Job.cpp:337
 
-  if (ResponseFile == nullptr) {
+  Driver::CC1ToolFunc CC1Main = nullptr;
+
----------------
I think it would be clearer with a boolean "CallCC1" or something instead of a function pointer.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69825/new/

https://reviews.llvm.org/D69825





More information about the llvm-commits mailing list