[cfe-dev] Why clang needs to fork into itself?

Manuel Klimek klimek at google.com
Tue Jan 28 12:08:29 PST 2014


On Tue, Jan 28, 2014 at 2:38 AM, Richard Smith <metafoo at gmail.com> wrote:

> On Mon Jan 27 2014 at 4:51:40 PM, Yuri <yuri at rawbw.com> wrote:
>
>> On 01/27/2014 16:37, Jean-Daniel Dupas wrote:
>> > If you want to debug/profile clang, you can invoke it directly with the
>> -cc1 flag, and passing the right arguments.
>> >
>> > To get the full command line used to invoke the real compilation
>> process, you can use the -### argument:
>> >
>> > clang -### -c -emit-llvm c.cpp
>> >
>> > For the record, in the early days, the clang driver was a separate
>> binary that used to invoke the compiler (which was called ccc IIRC).
>> > Some time ago, the driver and the compiler were merged into a single
>> clang binary, but it continue to work the same way it used to do. That
>> explains why it executes itself.
>>
>> I see.
>> So I wrote up my proposal to make this opt-in:
>> http://llvm.org/bugs/show_bug.cgi?id=18638
>
>
> I don't think the reasons why we spawn another binary have really been
> captured in this thread. The biggest reason is that the clang driver
> accepts multiple files to compile:
>
>    clang foo.c bar.c baz.c -o thing
>
> ... and runs one compile process for each source file (and in this case,
> one link process for the binary). Crash recovery is just a nice side-effect
> of having a separate driver and frontend. The main benefit is that we get a
> consistent execution model regardless of the number of files passed to the
> driver.
>

But nowadays with modules we also have in-process compilation steps of
dependent modules without going through the whole driver enchilada, so is
this becoming an obsolete argument?

Cheers,
/Manuel


>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140128/62c64f5d/attachment.html>


More information about the cfe-dev mailing list