llvm dev - Oct 2014 - [LLVMdev] [cfe-dev] [RFC] Raising LLVM minimum required MSVC version to 2013 for trunk

> -----Original Message-----
> From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at
cs.uiuc.edu] On
> Behalf Of Aaron Ballman
> Sent: Monday, September 29, 2014 4:45 PM
> To: Chris Bieneman
> Cc: lldb-dev at cs.uiuc.edu; cfe-dev Developers; LLVM Developers Mailing
List
> Subject: Re: [cfe-dev] [LLVMdev] [RFC] Raising LLVM minimum required MSVC
> version to 2013 for trunk
> 
> On Fri, Aug 22, 2014 at 12:42 PM, Chris Bieneman <beanz at apple.com>
wrote:
> > Starting a new thread to loop in cfe-dev and lldb-dev. For those not
> > following along there has been a thread on llvm-dev about moving the
> minimum
> > required Visual Studio version to 2013. The motivating reason is this
> will
> > allow us to take advantage of a bunch of C++11 features that are not
> > supported by MSVC 2012. According to MSDN
> > (http://msdn.microsoft.com/en-us/library/hh567368.aspx) the list is:
> >
> > * Non-static data member initializers
> > * Variadic templates
> > * Initializer lists
> > * Default template arguments for function templates
> > * Expression SFINAE
> > * Alias templates
> > * Delegating constructors
> > * Explicit conversion operators
> > * Raw string literals
> > * Defaulted and deleted functions
> >
> > From the discussion on LLVM-dev it is also believed that this may ease
> some
> > development pain as people keep occasionally breaking LLVM trunk by
> using
> > language features not available in MSVC.
> >
> > Original thread:
> > http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/075900.html
> >
> > Chandler’s proposal for moving forward is as follows:
> > 1) Loop in cfe-dev and lldb-dev (Done!)
> > 2) Wait until this email fully circulates in digests and LLVM Weekly
so
> that
> > everyone who has an objection can voice it
> > 3) If there are no objections, Commit a change to the CMake build
which
> > errors on old MSVC versions
> > 4) Revert and fix buildbots
> > 5) Repeat 3 & 4 until no issues
> > 6) Once the change is live for a week with no issues, update the
> > documentation to reflect the minimum required MSVC version as 2013
> >
> > (http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-August/076090.html)
> >
> > Feedback is greatly appreciated.
> 
> This thread has sort of stalled without a resolution. Alex, has your
> team had the opportunity to weigh in on the subject yet?
I'm expecting to have our internal builds switched over later this
week.  Our investigations have shown no problems.
> 
> We have run into a hard situation where MSVC 2012 is missing a feature
> that we are currently relying on. We made some changes to ASTMatchers
> to reduce the number of symbols generated in order to not require
> /bigobj support (see http://reviews.llvm.org/D5485). This change
> relies on function templates with default arguments, which MSVC does
> not support (it generates a C4519 error in MSVC 2012), resulting in
> red bots (http://bb.pgr.jp/builders/ninja-clang-i686-msc17-
> R/builds/10721).
I have a sad bot failing to build in Debug mode, glad to know there's
a fix in the works.
> 
> This is a considerably more interesting case (at least to me) than
> hypothetical benefits -- if we retain MSVC 2012 support, we will also
> require /bigobj support, have slower compile times for ASTMatcher
> projects, and slower benchmarks for clang-tidy. This points to
> concrete benefits to expediting switching away from MSVC 2012, which
> is why I am pinging this thread again.
I guess I'm a little surprised that /bigobj is such a compile-time hit,
but haven't tried any benchmarking. Anyway, whatever works best for you.
--paulr
> 
> Thanks!
> 
> ~Aaron
> 
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev

> >
> > This is a considerably more interesting case (at least to me) than
> > hypothetical benefits -- if we retain MSVC 2012 support, we will also
> > require /bigobj support, have slower compile times for ASTMatcher
> > projects, and slower benchmarks for clang-tidy. This points to
> > concrete benefits to expediting switching away from MSVC 2012, which
> > is why I am pinging this thread again.
> 
> I guess I'm a little surprised that /bigobj is such a compile-time hit,
> but haven't tried any benchmarking. Anyway, whatever works best for
you.
> --paulr
I'm not 100% sure, but my understanding is that the huge number of template
instantiations is the root cause of the compile-time hit. It's the same root
cause that requires /bigobj to be needed, as each template instantiation
seems to need its own section? Therefore, /bigobj in itself probably doesn't
incur a compile-time hit, but rather the huge number of template instantiations
produced.
Aaron, did I understand correctly that moving to MSVC2013 would allow to
adapt the code so that no longer a huge number of templates need to be
instantiated?

Thanks,

Kristof

On Tue, Sep 30, 2014 at 4:57 AM, Kristof Beyls <kristof.beyls at arm.com>
wrote:
>> >
>> > This is a considerably more interesting case (at least to me) than
>> > hypothetical benefits -- if we retain MSVC 2012 support, we will
also
>> > require /bigobj support, have slower compile times for ASTMatcher
>> > projects, and slower benchmarks for clang-tidy. This points to
>> > concrete benefits to expediting switching away from MSVC 2012,
which
>> > is why I am pinging this thread again.
>>
>> I guess I'm a little surprised that /bigobj is such a compile-time
hit,
>> but haven't tried any benchmarking. Anyway, whatever works best for
you.
>> --paulr
>
> I'm not 100% sure, but my understanding is that the huge number of
template
> instantiations is the root cause of the compile-time hit. It's the same
root
> cause that requires /bigobj to be needed, as each template instantiation
> seems to need its own section? Therefore, /bigobj in itself probably
doesn't
> incur a compile-time hit, but rather the huge number of template
instantiations
> produced.
> Aaron, did I understand correctly that moving to MSVC2013 would allow to
> adapt the code so that no longer a huge number of templates need to be
instantiated?
That is correct -- MSVC 2013 supports the language feature needed for
that patch. That's not to say there aren't other solutions to the
problem which are portable across more compilers.

~Aaron

Hi,

To follow up from Paul last week:
> I'm expecting to have our internal builds switched over later this
> week.  Our investigations have shown no problems.
We've now updated our internal builds from 2012.4 (cl.exe 17.0.61030) to
2013.3 (cl.exe 18.00.30723).  Our automated testing over the weekend hasn't
shown any correctness issues so we plan to continue using it now..
>From some of the stats I've collected it seems to be a worthwhile
update.
On my own machine, the time for a full rebuild from clean of ALL_BUILD
(LLVM & Clang, Release + asserts + debug info, not using ninja) has
improved by 20%.  Doing a like-for-like build of various benchmarks and
games using clang built by VS2012 and VS2013, the clang build speed of a
typical -O2 -g build is somewhere between in the noise and 1% faster with
VS2013.  We've not yet observed any regressions in the speed of clang since
upgrading.

Cheers,

Greg Bedwell
SN Systems Ltd - Sony Computer Entertainment Group
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20141008/bbc5a233/attachment.html>

On Wed, Oct 8, 2014 at 12:17 PM, Greg Bedwell <gregbedwell at gmail.com>
wrote:
> Hi,
>
> To follow up from Paul last week:
>
>> I'm expecting to have our internal builds switched over later this
>> week.  Our investigations have shown no problems.
>
> We've now updated our internal builds from 2012.4 (cl.exe 17.0.61030)
to
> 2013.3 (cl.exe 18.00.30723).  Our automated testing over the weekend
hasn't
> shown any correctness issues so we plan to continue using it now..
>
> From some of the stats I've collected it seems to be a worthwhile
update.
> On my own machine, the time for a full rebuild from clean of ALL_BUILD
(LLVM
> & Clang, Release + asserts + debug info, not using ninja) has improved
by
> 20%.  Doing a like-for-like build of various benchmarks and games using
> clang built by VS2012 and VS2013, the clang build speed of a typical -O2 -g
> build is somewhere between in the noise and 1% faster with VS2013. 
We've
> not yet observed any regressions in the speed of clang since upgrading.
Great, thank you for the feedback!

~Aaron