<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 22, 2011, at 9:41 AM, Douglas Gregor wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On Apr 21, 2011, at 4:53 AM, Francois Pichet wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>On Thu, Apr 14, 2011 at 11:23 AM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On Apr 14, 2011, at 8:22 AM, Francois Pichet wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">On Sat, Apr 9, 2011 at 1:59 PM, Francois Pichet <<a href="mailto:pichet2000@gmail.com">pichet2000@gmail.com</a>> wrote:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Hi here is an updated patch<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">On Sat, Mar 26, 2011 at 7:29 PM, Douglas Gregor <<a href="mailto:dgregor@apple.com">dgregor@apple.com</a>> wrote:<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">Nifty. A bunch of comments below.<br></blockquote></blockquote></blockquote></blockquote><br><br>Hi here is an update patch.<br><br>The main difference with this patch is that template parsing is done<br>only if an instantiation is actually needed.<br><br>The only problem is that my patch doesn't correctly diagnostic<br>multiple definition of template code. I put a FIXME and I'll look at<br>this problem later (soon).<br><br>With this patch all Microsoft C++ headers parse if there is no<br>instantiation requested.<br>With instantiation requested there are only 3-4 remaining problems.<br></div></blockquote><div><br></div><div>That's a *huge* improvement. Congrats!</div><br><blockquote type="cite"><div>There is a 4-5% speed improvement when doing a clang self hosting with<br>delayed template parsing.<br>./configure --enable-optimized CC=/usr/local/bin/clang<br>CXX=/usr/local/bin/clang++<br>make CXXFLAGS=-fdelayed-template-parsing.<font class="Apple-style-span"><font class="Apple-style-span" color="#144FAE"><br></font></font></div></blockquote><div><br></div><div>4-5% is quite good. That gives us a decent upper bound for what we could achieve when using -fdelayed-template-parsing (+ as-yet-unimplemented name lookup tricks) as an optimization rather than as a way to better emulate MSVC.</div><div><br></div><blockquote type="cite"><div>On my Mac Mini this is shaving about 90 seconds out of 33 minutes for<br>a complete build. The resulting binary passes all the clang test.<br></div></blockquote><br></div><div>Very cool.</div><div><br></div><div><div>@@ -1489,6 +1494,8 @@</div><div><br></div><div> Opts.MathErrno = Args.hasArg(OPT_fmath_errno);</div><div> Opts.InstantiationDepth = Args.getLastArgIntValue(OPT_ftemplate_depth, 1024,</div><div> Diags);</div><div>+ Opts.DelayedTemplateParsing = Args.hasArg(OPT_fdelayed_template_parsing) ||</div><div>+ Opts.Microsoft;</div><div> Opts.NumLargeByValueCopy = Args.getLastArgIntValue(OPT_Wlarge_by_value_copy,</div><div> 0, Diags);</div><div> Opts.MSBitfields = Args.hasArg(OPT_mms_bitfields);</div></div><div><br></div><div>This isn't the right place to perform the check for Microsoft mode, since "clang -cc1" shouldn't be making this decision. Rather, the driver should set the default for -fdelayed-template-parsing based on whether the user has requested Microsoft mode, e.g., here:</div><div><br></div><div><div>+ // -fno-delayed-template-parsing is default.</div><div>+ if (Args.hasFlag(options::OPT_fdelayed_template_parsing,</div><div>+ options::OPT_fno_delayed_template_parsing,</div><div>+ false))</div><div>+ CmdArgs.push_back("-fdelayed-template-parsing");</div></div><div><br></div><div>That said, I really don't like tying this to -fms-extensions. It's the first place where we've really taken the big step from adding Microsoft-specific extensions to implementing an non-conforming feature specifically for Microsoft compatibility. It's great for users that need to parse Microsoft headers, but it could be harmful to users who want their C++ code relatively clean but also need some of the Microsoft extensions.</div><div><br></div><div>Could we instead add some kind of -fms-compatibility flag, and turn on -fdelayed-template-parsing that way?</div></div></blockquote></div><br><div>How about taking away the "|| Opts.Microsoft" check now, and committing the rest of the delayed-template-parsing bit? Then we can sort out the -fms-extensions/-fms-compatibility stuff separately.</div><div><br></div><div>Thanks for working on this, it's very, very cool!</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>- Doug</div></body></html>