<div>On Wed Jan 29 2014 at 11:37:22 AM, Alp Toker <<a href="mailto:alp@nuanti.com">alp@nuanti.com</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On 29/01/2014 18:15, Ted Kremenek wrote:<br>
> On Jan 29, 2014, at 9:55 AM, Richard Smith <<a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a><br>
> <mailto:<a href="mailto:metafoo@gmail.com" target="_blank">metafoo@gmail.com</a>>> wrote:<br>
><br>
>> On Wed Jan 29 2014 at 12:35:23 AM, Ted Kremenek <<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a><br>
>> <mailto:<a href="mailto:kremenek@apple.com" target="_blank">kremenek@apple.com</a>>> wrote:<br>
>><br>
>>     On Jan 28, 2014, at 11:58 PM, Richard Smith<br>
>>     <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a> <mailto:<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><u></u>> wrote:<br>
>><br>
>>>     That said, most users of the compiler don't actually *want* a<br>
>>>     driver. They want just a .c* -> .o compiler, not a<br>
>>>     multi-source-file cross-language compiler + assembler + linker +<br>
>>>     kitchen sink, and it makes sense to me to optimize for the<br>
>>>     single-source, -c case.<br>
>><br>
>>     I don’t really know if it matters what most users “want.” We<br>
>>     still need to support the kitchen sink model; it’s never going to<br>
>>     go away.<br>
>><br>
>><br>
>> I think it does matter, because it helps us set our priorities. In<br>
>> particular, if we can make single-source -c builds measurably faster,<br>
>> that has benefits for a lot of users, even if we leave all other<br>
>> modes alone.<br>
>><br>
>>     By “optimize”, what specifically do you propose/suggest?<br>
>><br>
>><br>
>> Nothing concrete, merely that we shouldn't dismiss this out of hand.<br>
>> For instance, if we can tell people to run -c --disable-fork for a<br>
>> measurable speedup (with a corresponding degradation in crash<br>
>> recovery), that might be valuable to some.<br>
><br>
> I agree that making single source builds faster is a case worth<br>
> optimizing.<br>
<br>
Hi Richard, Ted,<br>
<br>
I have a very simple solution to get started with:<br>
<br>
+ bool TryInProcess = getArgs().hasArg(options::OPT_<u></u>fno_crash_diagnostics);<br>
+ if (TryInProcess && C.getExecutable() ==<br>
getDriver().<u></u>getClangProgramPath()) {<br>
+ const ArgStringList &Arguments = C.getArguments();<br>
...<br>
+ Res = main(Argv.size() - 1, Argv.data());<br>
+ } else<br>
<br>
This passes all but one of the tests (which appears to be a genuine bug<br>
in the preprocessor that I'm looking to fix now).<br>
<br>
All -cc1, -cc1as, -E and a couple of other invocations get run<br>
in-process with no apparent regressions.<br>
<br>
This setup parallels the way we skip expensive checks in Parse and Sema<br>
when we know a diagnostic is ignored and it shouldn't have any<br>
observable effect to the user other than fewer PIDs and invocations.<br>
<br>
I'd like to move forward with this so we can start to experiment with<br>
in-process operation focusing on the single input case Richard mentioned.<br>
<br>
It's not particularly hi-tech, but that's what makes it kind of neat.<br>
What do you think?<br></blockquote><div><br></div><div>I'd be surprised if it works as-is (I'd expect we have globals that misbehave when treated this way). Also, invoking 'main' in this way is ill-formed, so we'd need to extract a 'clang_recursive_main' or similar (and mark it __attribute__((weak)) so we don't require tools to provide it).</div>
<div><br></div><div>This seems like a good way forward for extracting performance numbers, and on the basis of those we can decide if this is worth pursuing. I don't think it's worth upstreaming until you have such numbers (maybe you could mail out a patch so interested parties can profile it?).</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Alp.<br>
<br>
<br>
><br>
>>     Even the .c -> .o compiler benefits from process isolation for<br>
>>     the purpose of crash reporting. Perhaps there are alternate<br>
>>     solutions for reporting crashes, but they are a bit speculative<br>
>>     at this point.<br>
>><br>
>>     I also haven’t seen any numbers mentioned on this thread that<br>
>>     justify “optimizing” anything, at least from a performance<br>
>>     perspective. I’m not saying there isn’t a possible performance<br>
>>     win here by eliminating the posix_spawn call, but that hasn’t<br>
>>     been justified yet (or if it has, I apologize that I haven’t seen<br>
>>     it). Or perhaps this discussion isn’t about optimizing<br>
>>     performance, but refining the driver design. In that case, it’s<br>
>>     not clear to me what specific problems are being tackled here<br>
>>     other than possibly making the compiler a little easier to debug<br>
>>     or profile.<br>
>><br>
>><br>
>> I think the changes proposed on this thread will make the driver<br>
>> design more complex. I'd also like to see some numbers.<br>
><br>
> Agreed.<br>
><br>
><br>
> ______________________________<u></u>_________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">cfe-dev@cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/cfe-dev</a><br>
<br>
--<br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</blockquote>