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

[Richard Smith]

On Wed Jan 29 2014 at 12:35:23 AM, Ted Kremenek <kremenek at apple.com> wrote:

> On Jan 28, 2014, at 11:58 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> That said, most users of the compiler don't actually *want* a driver. They
> want just a .c* -> .o compiler, not a multi-source-file cross-language
> compiler + assembler + linker + kitchen sink, and it makes sense to me to
> optimize for the single-source, -c case.
>
>
> I don't really know if it matters what most users "want."  We still need
> to support the kitchen sink model; it's never going to go away.
>

I think it does matter, because it helps us set our priorities. In
particular, if we can make single-source -c builds measurably faster, that
has benefits for a lot of users, even if we leave all other modes alone.


> By "optimize", what specifically do you propose/suggest?
>

Nothing concrete, merely that we shouldn't dismiss this out of hand. For
instance, if we can tell people to run -c --disable-fork for a measurable
speedup (with a corresponding degradation in crash recovery), that might be
valuable to some.


> Even the .c -> .o compiler benefits from process isolation for the purpose
> of crash reporting.  Perhaps there are alternate solutions for reporting
> crashes, but they are a bit speculative at this point.
>
> I also haven't seen any numbers mentioned on this thread that justify
> "optimizing" anything, at least from a performance perspective.  I'm not
> saying there isn't a possible performance win here by eliminating the
> posix_spawn call, but that hasn't been justified yet (or if it has, I
> apologize that I haven't seen it).  Or perhaps this discussion isn't about
> optimizing performance, but refining the driver design.  In that case, it's
> not clear to me what specific problems are being tackled here other than
> possibly making the compiler a little easier to debug or profile.
>

I think the changes proposed on this thread will make the driver design
more complex. I'd also like to see some numbers.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140129/3a150334/attachment.html>