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

[Ted Kremenek]

On Jan 29, 2014, at 9:55 AM, Richard Smith <metafoo at gmail.com> wrote:

> 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.

I agree that making single source builds faster is a case worth optimizing.

>  
> 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.

Agreed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140129/7edee4e0/attachment.html>