[llvm-dev] A Short Policy Proposal Regarding Host Compilers

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a).  

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
On 05/11/2018 03:37 PM, Keane, Erich via llvm-dev wrote:

> Hi All-
> As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:
>
> Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a).  
>
> The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8
>
> /End Proposal
>
>
> *: To Be Bikeshed

One thing to consider (and, as far as I understand, is one of the main
issue) is that you can have an up-to-date compiler using an old C++
standard library. One example would be to install Clang 6 in Debian
jessie (using i.e. http://apt.llvm.org/jessie/). libstdc++ is the one of
GCC 4.9 in this system, and I think their would be issues in this case
compiling C++14 code.

The idea would be to also add checks for the version of the standard C++
library that is used to compile LLVM. It is maybe also possible to use
an up-to-date libc++ and statically compile LLVM with it, but I've never
tried it thought.

--
Adrien.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.

On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:
Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). 

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev

Based on my reading of the release pages (https://gcc.gnu.org/releases.html and http://releases.llvm.org/)

6/5 would make GCC 4.7 and Clang 3.1 required, and GCC 4.8 and Clang 3.3 the first to not warn.

 

6/5 is surprisingly close to making the policy conform to exactly our current time-lag, where we are GCC4.8 (instead of 4.7) and Clang 3.1 (also 3.1).

 

-Erich

 

From: Andrew Kelley [mailto:[hidden email]]
Sent: Friday, May 11, 2018 8:58 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

 

I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.

 

On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:

Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). 

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev

However, 6/5 means we would not be moving ahead to full C++17 until 2024.  Can you hold back the tidal wave of developer angst that long? J

Retrospectively, that policy means we would only now be starting the transition period to MSVC 2013, which wouldn't even enable C++11 IIRC.  But MSVC is not closely tied to distros the way gcc is, so applying the same policy there might not be appropriate.

--paulr

 

From: llvm-dev [mailto:[hidden email]] On Behalf Of Keane, Erich via llvm-dev
Sent: Friday, May 11, 2018 12:05 PM
To: [hidden email]
Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

 

Based on my reading of the release pages (https://gcc.gnu.org/releases.html and http://releases.llvm.org/)

6/5 would make GCC 4.7 and Clang 3.1 required, and GCC 4.8 and Clang 3.3 the first to not warn.

 

6/5 is surprisingly close to making the policy conform to exactly our current time-lag, where we are GCC4.8 (instead of 4.7) and Clang 3.1 (also 3.1).

 

-Erich

 

From: Andrew Kelley [mailto:[hidden email]]
Sent: Friday, May 11, 2018 8:58 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

 

I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.

 

On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:

Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). 

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

 


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
I'd be opposed to 6/5, given where it would leave us.
It's simply hard to see a compelling reason to leave things that long.

In particular, given this is about what it takes to produce a binary release of clang/llvm from trunk (and not what it takes to use one), i'd like to see some evidence/argument that using 3/1.5 would actually have a material affect on the number of contributions, etc.
(I have doubts it would have any affect on the abliity of new developers to start contributing, etc).
All of the clang/llvm based tools i have around (cquery, rtags, you name it) all download and ship binary releases of clang/llvm (and FWIW, they ship and use 1-2 year old releases).
It's also unclear to me it makes sense to try to make sure any user can compile the latest version - for example, researchers using it almost never keep up with trunk, even with our current policy that supports things for longer.  They stick with the version that existed when they started.
So it's unclear that we are doing a thing users actually want in practice anyway :)

Finally,  given the rate of support for newer C++ standards in LLVM/GCC seems to be accelerating and not slowing down (AFAICT), keeping a time period this long will just put you farther and farther behind over time.

It may be better to simply express it in terms of releases, and say "we support the past 2/3 major gcc releases, the past 2/3 major clang releases, and the past 2 major msvc releases"





On Fri, May 11, 2018 at 8:58 AM, Andrew Kelley via llvm-dev <[hidden email]> wrote:
I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.

On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:
Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). 

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
Hi,

@Erich, thanks for putting this together :).

On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <[hidden email]> wrote:

I'd be opposed to 6/5, given where it would leave us.
It's simply hard to see a compelling reason to leave things that long.

In particular, given this is about what it takes to produce a binary release of clang/llvm from trunk (and not what it takes to use one), i'd like to see some evidence/argument that using 3/1.5 would actually have a material affect on the number of contributions, etc.
(I have doubts it would have any affect on the abliity of new developers to start contributing, etc).

+ 1.

All of the clang/llvm based tools i have around (cquery, rtags, you name it) all download and ship binary releases of clang/llvm (and FWIW, they ship and use 1-2 year old releases).
It's also unclear to me it makes sense to try to make sure any user can compile the latest version - for example, researchers using it almost never keep up with trunk, even with our current policy that supports things for longer.  They stick with the version that existed when they started.

So it's unclear that we are doing a thing users actually want in practice anyway :)

Yep, I have the same doubts. Anecdotally, I've got a few hobby projects I haven't rebased since.. 3.4? I don't have a list on hand, but I've definitely seen papers from groups that do the same thing.


Finally,  given the rate of support for newer C++ standards in LLVM/GCC seems to be accelerating and not slowing down (AFAICT), keeping a time period this long will just put you farther and farther behind over time.

It may be better to simply express it in terms of releases, and say "we support the past 2/3 major gcc releases, the past 2/3 major clang releases, and the past 2 major msvc releases"

I'd prefer this to imposing a fixed wait period of 3 years. We could add a deprecation warning for compiler version X when (X+1) is released, and switch to (X+1) when (X+2) is out. I can see this breaking down if some LTS distro continues to ship version X, but that's in issue in the 3/1.5 scheme as well, and we can make specific exceptions as needed.

I see the 3/1.5 scheme as basically a more conservative version of this, so I'd be OK with that too.

vedant




On Fri, May 11, 2018 at 8:58 AM, Andrew Kelley via llvm-dev <[hidden email]> wrote:
I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.

On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:
Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). 

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
On Sat, May 12, 2018 at 5:10 AM Vedant Kumar via llvm-dev <
[hidden email]> wrote:

> Hi,

> @Erich, thanks for putting this together :).

> On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <
[hidden email]> wrote:

> I'd be opposed to 6/5, given where it would leave us.
> It's simply hard to see a compelling reason to leave things that long.

> In particular, given this is about what it takes to produce a binary
release of clang/llvm from trunk (and not what it takes to use one), i'd
like to see some evidence/argument that using 3/1.5 would actually have a
material affect on the number of contributions, etc.
> (I have doubts it would have any affect on the abliity of new developers
to start contributing, etc).


> + 1.

> All of the clang/llvm based tools i have around (cquery, rtags, you name
it) all download and ship binary releases of clang/llvm (and FWIW, they
ship and use 1-2 year old releases).
> It's also unclear to me it makes sense to try to make sure any user can
compile the latest version - for example, researchers using it almost never
keep up with trunk, even with our current policy that supports things for
longer.  They stick with the version that existed when they started.


> So it's unclear that we are doing a thing users actually want in practice
anyway :)


> Yep, I have the same doubts. Anecdotally, I've got a few hobby projects I
haven't rebased since.. 3.4? I don't have a list on hand, but I've
definitely seen papers from groups that do the same thing.


> Finally,  given the rate of support for newer C++ standards in LLVM/GCC
seems to be accelerating and not slowing down (AFAICT), keeping a time
period this long will just put you farther and farther behind over time.


> It may be better to simply express it in terms of releases, and say "we
support the past 2/3 major gcc releases, the past 2/3 major clang releases,
and the past 2 major msvc releases"


I'm a little hesitant about this because:

- This assumes that the release cadence of these projects won't change.
Tying up the LLVM HEAD to the release rate of other projects seem dangerous.

- Using time instead seems much easier to predict and easier to plan around
(by construction I think). ;)


> I'd prefer this to imposing a fixed wait period of 3 years. We could add
a deprecation warning for compiler version X when (X+1) is released, and
switch to (X+1) when (X+2) is out. I can see this breaking down if some LTS
distro continues to ship version X, but that's in issue in the 3/1.5 scheme
as well, and we can make specific exceptions as needed.


I'm a little confused here.

I suspect the policy applies to a particular state of HEAD/trunk/master,
which means it mostly affects those who work directly on the features being
delivered in HEAD/trunk/master. For released versions, those would have
already sailed (frozen in time) and therefore we can't back-apply the
policy.

Given that, I don't see how the following won't work:

- Applying the policy to HEAD/trunk/master will/should affect the users
that *don't* track HEAD/trunk/master anyway.

- Giving a recommendation of the requirements in terms of a bootstrapping
path seems more manageable, no? i.e. if LLVM version N can build LLVM HEAD,
then if the LTS distributions can build LLVM N then they should be able to
get to LLVM HEAD.

If we're optimising for users of released versions, then there's a path for
those packaging the release(s) to use the bootstrapping approach to get to
a specific version, if the "host compiler" for their distribution can't
build the new release directly.

Now there's a real problem with the system ABI compatibility unless LLVM
decides that it will rely/require that it will only fully support working
with libc++ with the tools. With the libraries, that's a much harder
problem to solve, but I suspect the bootstrapping approach might also make
it feasible.

I understand that bootstrapping LLVM with itself introduces a lot of
potential for complexity and/or subtle bugginess along the way. But the
risk of that seems much less now, compared to tying the project's progress
to what other projects prioritise (e.g. OS distributions, other compilers,
etc.).

> I see the 3/1.5 scheme as basically a more conservative version of this,
so I'd be OK with that too.


Just to be clear, 3/1.5 works for me too. :)

Cheers

--
Dean
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
On Sat, May 12, 2018 at 12:56 PM, Dean Michael Berris via llvm-dev <[hidden email]> wrote:
- Giving a recommendation of the requirements in terms of a bootstrapping
path seems more manageable, no? i.e. if LLVM version N can build LLVM HEAD,
then if the LTS distributions can build LLVM N then they should be able to
get to LLVM HEAD.

​I agree with this, except that the intermediate​ compiler could be llvm or gcc (or another).

I think building *one* intermediate compiler is not too onerous.

clang 3.4 is probably a good choice if you only want to use C++14 features, not C++17. It demands only C++98 from the system compiler, but supports C++11 and C++14.

If you want to use C++17 features then you need a Clang that itself needs the system compiler to support C++11 compiler to build it. Maybe we're there already.


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
On 11 May 2018, at 17:54, Daniel Berlin via llvm-dev <[hidden email]> wrote:
>
> It's also unclear to me it makes sense to try to make sure any user can compile the latest version - for example, researchers using it almost never keep up with trunk, even with our current policy that supports things for longer.  They stick with the version that existed when they started.

This may be true (though we always follow trunk), but it isn’t something that we should encourage.  I’ve seen (from the reviewer side) papers rejected because people worked based on an old version of LLVM.  This has two problems for research:

1. Their baseline is out of date.  Okay, so you showed a speedup versus a version of LLVM from 2-3 years ago, but has trunk improved since then?  Has trunk implemented something that makes your optimisation worse, or a better analysis that makes it better?  In short, are your benchmarks showing anything useful relative to the state of the art?  When reviewing, I take benchmarking against any version of LLVM more than six months old as an indication that their work has been superseded by something in trunk and they want to try to confuse reviewers.

2. Their research is likely to be lower impact, because upstreaming something based on an old release requires a lot of refactoring before you get to the relevant state.  Again, not following trunk implies that they don’t want people to be able to use their work or perform apples-to-apples comparisons, so it gets a lower score when reviewing.

I know of a couple of accepted CGO papers that showed some interesting improvements, but when the authors came to engage with the community to upstream their results, they found that they didn’t show any speedup in the version rebased on trunk.  This wouldn’t have happened if they’d been following trunk.  I’d prefer that we encouraged people to do good research, rather than focus on supporting people doing bad research.

David

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev


On Sat, May 12, 2018 at 2:38 AM, David Chisnall <[hidden email]> wrote:
On 11 May 2018, at 17:54, Daniel Berlin via llvm-dev <[hidden email]> wrote:
>
> It's also unclear to me it makes sense to try to make sure any user can compile the latest version - for example, researchers using it almost never keep up with trunk, even with our current policy that supports things for longer.  They stick with the version that existed when they started.

This may be true (though we always follow trunk), but it isn’t something that we should encourage.

Sure, but this is very orthogonal to this discussion, which is precisely my point - our host compilation policy, which has allowed trunk compilation with fairly old compilers for years, has had no visible effect on what researchers do.

--Dan


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
I want to chime in with an alternate perspective.  Not a counter argument per se, but something to consider.

When we first started evaluating LLVM, we were stuck with an absolutely ancient version of gcc.  We could use a newer compiler for LLVM, but if there was an ABI breakage - like the one moving to C++11 - between our build compiler and our choice of compiler for LLVM, we were pretty much dead in the water.  I honestly don't know if we'd had a problem at the time, that we'd have ever moved past it.  Or to say it differently, our initial evaluation period had a fixed number of person months allocated.  If we'd spent those person months fighting build systems, it's very likely we'd have not reached a point sufficient to justify a "go" on the rest of the project. 

Just to highlight, the primary issue to be concerned about is ABI compatibility between whatever version of the compiler is required to build LLVM and the "build compiler" used for everything else.  Having the compiler itself out of sync is (usually) not an issue, but having an ABI break - intentional or otherwise - is a show stopper.

Philip

On 05/11/2018 09:54 AM, Daniel Berlin via llvm-dev wrote:
I'd be opposed to 6/5, given where it would leave us.
It's simply hard to see a compelling reason to leave things that long.

In particular, given this is about what it takes to produce a binary release of clang/llvm from trunk (and not what it takes to use one), i'd like to see some evidence/argument that using 3/1.5 would actually have a material affect on the number of contributions, etc.
(I have doubts it would have any affect on the abliity of new developers to start contributing, etc).
All of the clang/llvm based tools i have around (cquery, rtags, you name it) all download and ship binary releases of clang/llvm (and FWIW, they ship and use 1-2 year old releases).
It's also unclear to me it makes sense to try to make sure any user can compile the latest version - for example, researchers using it almost never keep up with trunk, even with our current policy that supports things for longer.  They stick with the version that existed when they started.
So it's unclear that we are doing a thing users actually want in practice anyway :)

Finally,  given the rate of support for newer C++ standards in LLVM/GCC seems to be accelerating and not slowing down (AFAICT), keeping a time period this long will just put you farther and farther behind over time.

It may be better to simply express it in terms of releases, and say "we support the past 2/3 major gcc releases, the past 2/3 major clang releases, and the past 2 major msvc releases"





On Fri, May 11, 2018 at 8:58 AM, Andrew Kelley via llvm-dev <[hidden email]> wrote:
I second this proposal, and I make a motion to lengthen 3/1.5 to 6/5.

On Fri, May 11, 2018 at 9:37 AM, Keane, Erich via llvm-dev <[hidden email]> wrote:
Hi All-
As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:

Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a). 

The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

/End Proposal


*: To Be Bikeshed
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev




_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev



_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev

On Sat, 12 May 2018 at 11:26 am, Bruce Hoult <[hidden email]> wrote:
On Sat, May 12, 2018 at 12:56 PM, Dean Michael Berris via llvm-dev <[hidden email]> wrote:
- Giving a recommendation of the requirements in terms of a bootstrapping
path seems more manageable, no? i.e. if LLVM version N can build LLVM HEAD,
then if the LTS distributions can build LLVM N then they should be able to
get to LLVM HEAD.

​I agree with this, except that the intermediate​ compiler could be llvm or gcc (or another).

Why not just say that LLVM is required as the intermediate compiler, when bootstrapping? I can see this being an issue with targets/platforms where the required intermediate compiler might not support that backend yet, but they’d have the same problem if the host compiler can’t get to LLVM HEAD yet anyway. That makes me think that to solve that problem, developers interested in making LLVM work for that platform will have to do something like cross-compiling while working to get it working upstream anyway — and then the host compiler requirements will apply to them.

In fact I *think* this is how we’d gotten the Windows port of clang working with MSVC as the host compiler. I could be wrong, in which case I’d be happy to be corrected.

The question becomes whether we’d need to impose that on all other developers/users tracking HEAD (i.e. hold them back because some users might need a special set-up).


I think building *one* intermediate compiler is not too onerous.

clang 3.4 is probably a good choice if you only want to use C++14 features, not C++17. It demands only C++98 from the system compiler, but supports C++11 and C++14.

If you want to use C++17 features then you need a Clang that itself needs the system compiler to support C++11 compiler to build it. Maybe we're there already.

This is my same thinking. We can already find a way to get LLVM to build first then build different versions progressively to get the to language standard we’d like to use. This seems the most forward compatible approach compared to the alternative (status quo).
--
Dean

_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
In reply to this post by Adam Nemet via llvm-dev
On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote:
> Hi All-
> As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:
>
> Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a).  
>
> The 3-years/1.5 years would result in our minimum GCC/Clang becoming: GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

Historically 3/1.5 would have caused us problems on FreeBSD, but
we're moving to supporting all architectures via an external
toolchain[0] so I don't think it will have a major impact.  We'll
have to amend our statement of which systems you can bootstrap from
to include the need to install a compiler package in some cases (or
be more aggressive about merging new compiler versions to stable
branches).

-- Brooks

[0] Some of them purely external due to a lack of viable LLVM support
and a policy against GPLv3 licenses in the tree.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
I've heard just about zero opposition to this, so I've put a code review together here: https://reviews.llvm.org/D47073
With the intent of either implementing this policy change, or encouraging further discussion/bikeshed.

Thanks all!
-Erich

-----Original Message-----
From: Brooks Davis [mailto:[hidden email]]
Sent: Sunday, May 13, 2018 10:34 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote:
> Hi All-
> As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:
>
> Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a).  
>
> The 3-years/1.5 years would result in our minimum GCC/Clang becoming:
> GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

Historically 3/1.5 would have caused us problems on FreeBSD, but we're moving to supporting all architectures via an external toolchain[0] so I don't think it will have a major impact.  We'll have to amend our statement of which systems you can bootstrap from to include the need to install a compiler package in some cases (or be more aggressive about merging new compiler versions to stable branches).

-- Brooks

[0] Some of them purely external due to a lack of viable LLVM support and a policy against GPLv3 licenses in the tree.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Reply | Threaded
Open this post in threaded view
|

Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

Adam Nemet via llvm-dev
Hi all-
I just wanted to bump this again, I know I sent it out on a Friday :)  I realize this is a minor code change with significant implications, so it seems to me that I should ensure it gets extensive exposure.
See the review here: https://reviews.llvm.org/D47073
-Erich

-----Original Message-----
From: Keane, Erich
Sent: Friday, May 18, 2018 8:26 AM
To: [hidden email]
Subject: RE: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

I've heard just about zero opposition to this, so I've put a code review together here: https://reviews.llvm.org/D47073 With the intent of either implementing this policy change, or encouraging further discussion/bikeshed.

Thanks all!
-Erich

-----Original Message-----
From: Brooks Davis [mailto:[hidden email]]
Sent: Sunday, May 13, 2018 10:34 AM
To: Keane, Erich <[hidden email]>
Cc: [hidden email]
Subject: Re: [llvm-dev] A Short Policy Proposal Regarding Host Compilers

On Fri, May 11, 2018 at 01:37:22PM +0000, Keane, Erich via llvm-dev wrote:
> Hi All-
> As we all know, the C++14 discussion is flaring up again.  Chandler brought up that he would like a concrete plan to switch.  In my opinion, this is insufficient, as it will result in us simply having this discussion AGAIN next release.  Instead, I would prefer us to have a concrete Policy on our host compilers.  That way, changes like this are unsurprising to our users, and advance our codebase sufficiently.  I believe the arguments for/against upgrading have been made repeatedly, so I won't repeat them here.  My proposal is thus:
>
> Starting with the Clang 7.0 release, we will officially support any major release of our host compilers (MSVC, GCC, Clang, ?ICC?) released in the past 3* years from our previous branch date to give trunk-developers time to transition (so for 7.0, 3 years before January 3, 2018).  This will be enforced via the CMake CheckCompilerVersion script (ala https://reviews.llvm.org/D46723).  ADDITIONALLY, a CMake warning will be issued for any major release less than 1.5* years old to give our users sufficient time to transition/upgrade their compilers.  Finally, our dependent C++ version will be the best released standard officially supported by the collection of compilers (for example, we'd support -C++20 if all compilers had std=c++20 or eqiv, but NOT std=c++2a).  
>
> The 3-years/1.5 years would result in our minimum GCC/Clang becoming:
> GCC5.1/Clang3.6.  We would WARN on anything older than GCC7.1/Clang3.8

Historically 3/1.5 would have caused us problems on FreeBSD, but we're moving to supporting all architectures via an external toolchain[0] so I don't think it will have a major impact.  We'll have to amend our statement of which systems you can bootstrap from to include the need to install a compiler package in some cases (or be more aggressive about merging new compiler versions to stable branches).

-- Brooks

[0] Some of them purely external due to a lack of viable LLVM support and a policy against GPLv3 licenses in the tree.
_______________________________________________
LLVM Developers mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev