llvm dev - May 2018 - A Short Policy Proposal Regarding Host Compilers

On Sat, May 12, 2018 at 5:10 AM Vedant Kumar via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi,
> @Erich, thanks for putting this together :).
> On May 11, 2018, at 9:54 AM, Daniel Berlin via llvm-dev <
llvm-dev at lists.llvm.org> 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

On Sat, May 12, 2018 at 12:56 PM, Dean Michael Berris via llvm-dev <
llvm-dev at lists.llvm.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180512/33914f0e/attachment.html>

On Sat, 12 May 2018 at 11:26 am, Bruce Hoult <bruce at hoult.org> wrote:
> On Sat, May 12, 2018 at 12:56 PM, Dean Michael Berris via llvm-dev <
> llvm-dev at lists.llvm.org> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180513/b52faed6/attachment.html>