llvm dev - Oct 2015 - Should I worry about test failures in a release?

On 13 October 2015 at 09:19, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> Oh... why do I need to rebase?
If your project is a product that wants to benefit from the advances
of LLVM over the years, you'll have to update the code to the newer
versions some time. Moreover, if you do find a bug, and it's in an old
version, you won't have the same response times than if it's in trunk.
Very likely, you'll get no response at all. As I said earlier, our
releases are "stable points in time", not final products that have
support contracts.

> I don't have the manpower or C++ expertise to hack on LLVM itself,
I've been
> planning to just use it. Since I'm just doing a proof of concept, I
> (hopefully) won't have to use any of the more experimental stuff.
Right, so sticking to the 3.7.0 release is probably your best bet.
It's feature complete on most targets (x86, ARM, MIPS, PPC), 32-bit
and 64-bit. You should be fine with that for a while.

> A different but related questons: Are minor releases of LLVM
> backwards-compatible?
Both ABI and API compatible. You should be safe migrating from 3.7.0
to .1 or .2 without a single change on your part. If there are any,
please report as a bug.

> Bitcode compatibility would be particularly
> interesting - can I assume that the LLVM toolchain is able to work with
> bitcode generated by earlier versions of the toolchain?
Not major versions. Those change considerably over the years, and
that's why people keep tracking trunk so closely. Then again, most
people that track trunk have teams big enough to cope with it. Those
that don't, generally prefer to stick to specific versions and hope
that the change log is enough to help them migrate.

cheers,
--renato

Thanks, that answered all questions.

One last detail: What's a major version? 3.8 or 4.0?

Regards,
Jo

Going from 3.6 to 3.7 would almost certainly break binary compatibility
between .bc files. You may be able to get away with it for some particular
use-cases (but in that case, it's by luck, not by design).

I'm not enough "part of the community" to say if there are rules
about what
can and can't change between certain levels of releases, but my general
understanding is that "as long as the change is good, it goes in"
[aside
from changes for example between 3.7.0 and 3.7.1, where there is a
guarantee that, modulo actual bugs or undefined behaviour, the two releases
are compatible].

I try to track "trunk" by updating every two-four weeks, and once
every few
of those updates, I need to make changes to my compiler project. Of course,
how many and what kind of changes will depend on what features of LLVM your
project is using. There are some parts of LLVM that are very stable, there
are others with more changes - but all appear to potentially change from my
experience.

The "not guarantee for compatibility between releases" is a good and a
bad
thing, where the bad part is the obvious extra work when something changes,
and the good part is that "things can be changed". I've worked
on/with
projects that have very strict rules of compatibility, where changes to ABI
and API are very difficult to make and everything has to be motivated,
debated, change-controlled and finally agreed with "customers" [in
quotes
as it's often some group within the overall company, but outside your own
group]. This approach makes for slow and often complex changes to "work
around" the fact that you can't actually make the change you want.
It's a
right pain to work with such systems too, even if it may seem like a good
idea at times. Most importantly, it is often harming innovation and
improvements, because of the bureaucracy involved in making changes.

--
Mats

On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Thanks, that answered all questions.
>
> One last detail: What's a major version? 3.8 or 4.0?
>
> Regards,
> Jo
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151013/49771d21/attachment.html>

On 13 October 2015 at 12:40, Joachim Durchholz via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> One last detail: What's a major version? 3.8 or 4.0?
3.8, 3.9, 4.0 are all "major" versions in my previous emails. ie,
that's what I meant. :)

I'm not good in keeping track of diverse nomenclatures, so that may
not be canon.

cheers,
-renato

Renato Golin via llvm-dev wrote on Tue, 13 Oct 2015:
> On 13 October 2015 at 09:19, Joachim Durchholz via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>
>> Bitcode compatibility would be particularly
>> interesting - can I assume that the LLVM toolchain is able to work with
>> bitcode generated by earlier versions of the toolchain?
>
> Not major versions.
..
> 3.8, 3.9, 4.0 are all "major" versions in my previous emails. ie,
> that's what I meant. :)
According to  
http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility ,  
"The bitcode format produced by a X.Y release will be readable by all  
following X.Z releases and the (X+1).0 release."

 From this I concluded that bitcode produced for 3.1 should be  
readable by every 3.x release and by 4.0.


Jonas