[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