llvm dev - Oct 2013 - [LLVMdev] [cfe-dev] RFC: A proposal to move toward using C++11 features in LLVM & Clang / bounding support for old host compilers

On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <clattner at apple.com>
wrote:
> On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at
google.com>
> wrote:> Concrete long term proposal:
> >
> > We support building with C++ toolchains which were released and widely
> available on their respective target platforms at least 2 years prior to
> the next 6-month-cycle release. Immediately after each branch of a release,
> mainline can move the bar forward by 6 months. Thus, each release should
> build with the four previous releases.
>
> I don't think it makes sense to have a hard policy like this.  It is
fine
> to have a goal that allows us to continue picking up new features over
> time, but I think each such change will have to be discussed (at length)
> with the specifics of which interesting host configurations we would be
> dropping.
>
I didn't really intend to indicate this would be a hard policy, more that
it would be the guideline. Part of the idea is that after each release
branch is cut we could evaluate what a reasonable baseline would look like.

I do think that 2 years is a good guideline, in part because two of the
three toolchains which impact us most already use time-driven release
cycles.

My hope is that we could *strive* for no more than two years of support for
older toolchains as a way to push ourselves to not let this slip.


An obvious other input to this decision would be exactly what Benjamin
brought up: we should look at what toolchain versions various OSes are
shipping with. However, I think the diversity of OS is too broad to be
easily explained in our getting started docs, etc. I would rather use the
OS situation to inform the particular versions of each toolchain that we
try to support, but to word the decision in terms of the toolchain versions.

> One short term caveat: Windows is special.
>
> I don't see how it is special.  We should just look at all of the
> compilers we need to support, and factor that set in.  We should continue
> to increment the baseline compilers over time, but a global "two year
old
> compilers only" policy doesn't make sense to me.  I also think
that windows
> will be the lowest bar anyway.
>
See above. I'm not interested in a hard policy. I think MSVC will end up
being special because we may realistically want a *narrower* set of
toolchains supported there given both the rapid advances of MSVC in the
last year, and the rapid changes to Clang and LLVM's role on that platform.

(And note, I misspoke previously, clearly MinGW is just GCC, I'm talking
about MSVC here)
> Now for the carrot: if we go with this plan, then immediately after
> branching for 3.4,  we would be able to use the vast majority of C++11
> features, targeting the following as the oldest toolchains supported
> through the 3.5 release timeframe:
> >
> > GCC 4.7
> > Clang 3.1
> > VS 2012
>
> This seems overly aggressive to me.  Why not start by baselining at VC++
> 2010, and bump up everything else to match?  That would give us some basic
> C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if
that
> goes well.
>
As others have pointed out, our baseline is already VS 2010, but our C++11
features have been held back by concern over GCC. I think the time frame is
right to jump all the way to GCC 4.7 as the target for our 3.5 release, and
would like to bump VS to 2012 at the same time if at all possible.

This isn't just a bump either, it brings things that I think will be very
useful:
- Fixed semantics for r-value references that is relevant to using move
semantics broadly in LLVM
- Range-based for loops, because as much as people say it "just reduces
boiler plate", omg it is so much nicer
- better concurrency support, notably we may be able to use the standard
atomics library (with some testing and restrictions) which have compiler
assistance behind them.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131027/2c5bf9ff/attachment.html>

On Oct 27, 2013, at 9:07 PM, Chandler Carruth <chandlerc at google.com>
wrote:
> On Sun, Oct 27, 2013 at 11:18 AM, Chris Lattner <clattner at
apple.com> wrote:
> On Sun, Oct 27, 2013 at 2:23 AM, Chandler Carruth <chandlerc at
google.com> wrote:> Concrete long term proposal:
> >
> > We support building with C++ toolchains which were released and widely
available on their respective target platforms at least 2 years prior to the
next 6-month-cycle release. Immediately after each branch of a release, mainline
can move the bar forward by 6 months. Thus, each release should build with the
four previous releases.
> 
> I don't think it makes sense to have a hard policy like this.  It is
fine to have a goal that allows us to continue picking up new features over
time, but I think each such change will have to be discussed (at length) with
the specifics of which interesting host configurations we would be dropping.
> 
> I didn't really intend to indicate this would be a hard policy, more
that it would be the guideline. Part of the idea is that after each release
branch is cut we could evaluate what a reasonable baseline would look like.
Ah ok, makes perfect sense then.
> I do think that 2 years is a good guideline, in part because two of the
three toolchains which impact us most already use time-driven release cycles.
> 
> My hope is that we could *strive* for no more than two years of support for
older toolchains as a way to push ourselves to not let this slip.
Sure, so long as there is room to be pragmatic :-)
> An obvious other input to this decision would be exactly what Benjamin
brought up: we should look at what toolchain versions various OSes are shipping
with. However, I think the diversity of OS is too broad to be easily explained
in our getting started docs, etc. I would rather use the OS situation to inform
the particular versions of each toolchain that we try to support, but to word
the decision in terms of the toolchain versions.
Right.
>  This seems overly aggressive to me.  Why not start by baselining at VC++
2010, and bump up everything else to match?  That would give us some basic
C++'11 features for 3.4, then we could bump it up to VS 2012 in 3.5 if that
goes well.
> 
> As others have pointed out, our baseline is already VS 2010, but our C++11
features have been held back by concern over GCC. I think the time frame is
right to jump all the way to GCC 4.7 as the target for our 3.5 release, and
would like to bump VS to 2012 at the same time if at all possible.
> 
> This isn't just a bump either, it brings things that I think will be
very useful:
> - Fixed semantics for r-value references that is relevant to using move
semantics broadly in LLVM
> - Range-based for loops, because as much as people say it "just
reduces boiler plate", omg it is so much nicer
> - better concurrency support, notably we may be able to use the standard
atomics library (with some testing and restrictions) which have compiler
assistance behind them.
I would also love to use standard types like std::unique_ptr, move semantics,
etc without worrying about conditional code or reinventing them in the llvm ADT
library.  I also have a personal love affair for range-based for loops, and I
expect a number of awesome new adaptors to paper over the Module::global_begin()
sorts of ranges.  It would also be great to get something like python's
enumerate function etc.  In short, you don't have to convince me about the
benefits of dropping old compilers! :-)

At root, my conservatism comes from not wanting to hurt adoption of LLVM.  The
hosts that I specifically care about are not the problem here, they are windows
and GCC users, and I am certainly not the expert on either of them, but it is
pretty obvious that LLVM is used by folks outside the core development group,
and making a huge change all at once is risky.

I suppose what I'm saying is that we are currently not using *any*
C++'11 features.  It seems like conservatively great progress for LLVM 3.4
to bump the minimum GCC requirement up to enable use of VC 2010-era features
(like rvalue refs and simple stdlib features), then jump to VC2012 features in
LLVM 3.5 assuming that goes well.  We're talking about a 6 month delta
between the two, and I think we'll learn a lot in the first step.  This also
helps stage out the inevitable "lets rewrite the codebase" churn over
more time.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/2efb7aa9/attachment.html>

One thing I want to call out:

On Mon, Oct 28, 2013 at 8:20 AM, Chris Lattner <clattner at apple.com>
wrote:
> I suppose what I'm saying is that we are currently not using *any*
C++'11
> features.  It seems like conservatively great progress for LLVM 3.4 to bump
> the minimum GCC requirement up to enable use of VC 2010-era features (like
> rvalue refs and simple stdlib features),

I am strongly opposed to this. Currently, we have people that are relying
on our C++98 status. This isn't actually about VC2010 issues, this is about
GCC support. I think it would be a disservice to change that in 3.4, only a
small number of weeks away from the branch point. That seems like very
little notice.

> then jump to VC2012 features in LLVM 3.5 assuming that goes well. 
We're
> talking about a 6 month delta between the two, and I think we'll learn
a
> lot in the first step.

I think the biggest jump will be to have a floor at all, and I think we
should just pick on that makes sense, and advertise the day lights out of
it. Put it in the 3.4 release notes that going forward we're going to be
dropping support for older toolchains, etc., etc. This will really help
manage the expectations of users, and ensure that folks plan adequately for
3.5 and get C++11-supporting toolchains installed on their systems, etc.

I have also heard no serious objection to the three versions I gave as a
baseline: VC2012, GCC 4.7 (the series, not any specific patch release), and
Clang 3.1.


This also helps stage out the inevitable "lets rewrite the codebase"
churn
> over more time.

I think this is a lost cause, and ultimately a (relatively) unimportant
one. We have great tools to cope with this as well. ;]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131028/60f558d6/attachment.html>