
LLVM 9.0 - AndyKelley
http://lists.llvm.org/pipermail/llvm-dev/2019-September/135304.html
======
brynet
Note that this release (9.x) marks the first to be no longer available under
the original permissive NCSA (BSD-like) LLVM license, going forward the LLVM
project has moved to an "Apache 2.0 with LLVM Exceptions" for everything. And
not just the compiler itself, but also sub-projects like the supporting
libc++/libc++abi standard libraries. This change only happened due to
corporate pressure, and was done without considering the larger impact towards
the open source community.

This will undoubtedly effect many projects and companies alike going forward,
but notably the OpenBSD project can no longer merge in new changes, which will
ship with 8.0.1 later this year in 6.6. The Apache 2.0 license is not
considered permissive enough to be included in the base system of OpenBSD, it
muddies the line between Copyright law and US Contract law; adding additional
restrictions related to patents that may terminate rights.

[https://lists.llvm.org/pipermail/llvm-
dev/2017-April/112300....](https://lists.llvm.org/pipermail/llvm-
dev/2017-April/112300.html)

[https://www.openbsd.org/policy.html](https://www.openbsd.org/policy.html)

It is very unfortunate that the LLVM project has ignored the concerns
expressed by developers of an open source operating system project that have
been eagerly adopting a clang based toolchain, across many platforms
(arm64/armv7/i386/amd64/octeon/..) by default, and has been working on new
innovative security mitigations (RETGUARD, ROPGadgetFixup framework, register
allocator rearranging) along the way.

I will take this opportunity to ask, if you're a current LLVM
developer/contributor, please consider making your changes also available
under the terms of the original permissive license. For example, explicitly
stating publically as such when mailing patchsets or pull requests. This would
save having to privately ask permission to backport changes on case-by-case
basis.

[https://github.com/llvm/llvm-
project/blob/release/8.x/clang/...](https://github.com/llvm/llvm-
project/blob/release/8.x/clang/LICENSE.TXT)

~~~
riscy
Doesn't the "LLVM Exceptions" part of the license take care of the patent
issue you mention?

"[...] if a court of competent jurisdiction determines that the patent
provision (Section 3), [...] conflicts with the conditions of the GPLv2, you
may retroactively and prospectively choose to deem waived or otherwise exclude
such Section(s) of the License [...]"

Source: [https://github.com/llvm/llvm-
project/blob/master/llvm/LICENS...](https://github.com/llvm/llvm-
project/blob/master/llvm/LICENSE.TXT#L208)

~~~
simcop2387
It wouldn't cover anything from OpenBSD, if as excerpted by you, it only
covers exceptions related to GPLv2 as I don't believe OpenBSD considers GPLv2
to be acceptable either.

~~~
brynet
> I don't believe OpenBSD considers GPLv2 to be acceptable either.

The GPLv3 is not acceptable in base at all, GPLv2 is unacceptable for new
code, but we still have a few examples in base, very few.

~~~
simcop2387
Ah that'd probably be why I was thinking it was any code, small difference
that's easy to forget about.

------
lpage
> "Support for asm goto, enabling for example the mainline Linux kernel for
> x86_64 to build with Clang"

This is big. Support for asm goto was merged into the mainline earlier this
year, but now it's released [1]. Aside from the obvious implications of this -
being able to build the kernel with LLVM - working with eBPF/XDP just got way
easier [2].

[1] [https://github.com/llvm/llvm-
project/commit/784929d0454c4df6...](https://github.com/llvm/llvm-
project/commit/784929d0454c4df6a98ef6fbbd1d30a6f71f9c16)

[2]
[https://www.spinics.net/lists/netdev/msg544057.html](https://www.spinics.net/lists/netdev/msg544057.html)

~~~
colechristensen
Can anyone give a good concise explanation as to why GOTO was _not_ in LLVM
from the beginning? It seems like something quite obvious to need. I can only
guess that it had something to do with their compliation strategy not being
able to deal with the ... nonlinearity* ... introduced by GOTO.

*Probably a better word for that

~~~
cesarb
This is not about "goto", it's about "asm goto", which is a gcc extension
which allows inline assembly (itself a gcc extension) to jump to a label
outside the inline assembly.

~~~
bumblebritches5
Inline assembly is part of the C11 standard as Asm("assembly goes here")

------
morning_gelato
>Support for asm goto, enabling for example the mainline Linux kernel for
x86_64 to build with Clang

This is great for Linux, no longer being dependent on a single compiler for
one of the most popular ISAs can only be a good thing for the overall health
of the project. To be clear, I have nothing against gcc.

~~~
wiz21c
2 cents prediction :

Android will leave linux (fuschia), linux will leave gcc because companies
developing the kernel will push for clang, clang will have media coverage, gcc
will therefore loose a huge user base and the power of the FSF will go south.

(as a free software zealot ( :-) ), I'm worried)

------
cryptonector
> LLVM will now remove stores to constant memory (since this is a
> contradiction) under the assumption the code in question must be dead. This
> has proven to be problematic for some C/C++ code bases which expect to be
> able to cast away ‘const’. This is (and has always been) undefined behavior,
> but up until now had not been actively utilized for optimization purposes in
> this exact way. For more information, please see: bug 42763 and post commit
> discussion.

This will break all sorts of code. Often we have things that are const for
callers of an API but not necessarily for the implementation of an API. Other
cases are where an API should have used const but didn't and then got partly
constified, and there are places where you still need to cast away const-ness.

~~~
rurban
Optimizing away even more calls of memset, memcpy or memmove is the completely
wrong way. gcc went down this bug and called it "optimization", now llvm did
the same. Can we at least keep at least one sane working compiler? At least
emit a prominent warning when "optimizing" away lib calls. This helps only
artificial benchmarks and will hurt everybody.

If an assignment to const memory is illegal, treat it as error, and don't
silently remove it.

Fear we'll have to blacklist clang-9 also, not just gcc-9.

~~~
mlindner
How about you fix your code to not rely on undefined behavior specific to a
compiler version? Poor coding standards is not an excuse.

------
KindOne
Repo of the Linux kernel built with clang:

[https://github.com/ClangBuiltLinux/linux](https://github.com/ClangBuiltLinux/linux)

~~~
cormacrelf
"This branch is even with torvalds:master." Does that mean there are no
patches necessary for any GCC builtins? Or does the actual clang-buildable
part live on another branch?

~~~
brackle
With LLVM 9, it is now possible to build the Linux kernel with no patches (for
x86_64).

[https://www.phoronix.com/scan.php?page=article&item=clang-
li...](https://www.phoronix.com/scan.php?page=article&item=clang-
linux-53&num=1)

~~~
ndesaulniers
Note: we also build+boot under CI:

* arm (v5, v6, v7)

* arm64 (v8)

* ppc32

* ppc64

* x86_64

* mips

[https://travis-ci.com/ClangBuiltLinux/continuous-
integration...](https://travis-ci.com/ClangBuiltLinux/continuous-
integration/builds/128315291)

------
shmerl
Meanwhile, Mesa developers merged ACO compiler for AMDGPU, as the future
replacement for llvm.

~~~
ndesaulniers
Fun fact; AMDGPU driver can't run when built with LLVM right now because they:

1\. build their driver with a stack alignment of 16B (standard for x86_64
userspace).

2\. use floating point in the kernel, which the kernel has limited support
for.

3\. The rest of the x86_64 kernel uses 8B stack alignment.

Code from 3 calls into 1. And then they have sse2 instructions in their driver
(double precision arithmetic). Guess what happens?

~~~
qalmakka
This has been patched and will be fixed in 5.4 if I recall correctly, right?

~~~
ndesaulniers
Heh, no, sorry, my fault. I wrote the patch you're referring to; I got it to
link. When AMD went to test it on hardware (which I don't have), they hit
alignment related general protection faults that I traced back to a movaps
instruction. I'm still working with CrOS and AMD folks to figure out what to
do, but there's a few questionable things that are going on in their driver
that have a few kernel devs confused. For now, people are just happy to see
AMD participate more in upstream kernel dev, but definitely some parts of
their driver will need to be rewritten I fear at this point.

------
nitwit005
> The optimizer will now convert calls to memcmp into a calls to bcmp in some
> circumstances.

What is the improvement from that change? I thought they were essentially the
same.

~~~
Someone
_memcmp_ has to find the first offset where the buffers differ, and check
which of them is larger.

 _bcmp_ only has to figure out whether the buffers differ. It doesn’t have to
figure out where they differ.

For example, for _s=1024_ , _bcmp_ can do (at most) 128 64-bit compares (using
vector registers, it could even use larger steps)

 _memcmp_ could do the same, with an additional “figure out where in the last
8-byte parts compared the difference lies”.

That’s an amount of work that’s independent of the buffer sizes, so it
wouldn’t add much, relatively, _if_ the buffers compared are large and the
difference (if any) most of the time is near the end of the buffers. I doubt
those ifs often hold, though.

~~~
tedunangst
This would be true, except bcmp has been removed from posix some years ago.
There's no particular requirement that a function called bcmp does what you
expect.

~~~
Someone
[http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#notewo...](http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#noteworthy-
optimizations):

 _”The optimizer will now convert calls to memcmp into a calls to bcmp in some
circumstances. Users who are building freestanding code (not depending on the
platform’s libc) without specifying -ffreestanding may need to either pass
-fno-builtin-bcmp, or provide a_ bcmp* function.”*

So, he’s, you may have to provide it yourself. I expect you can fairly easily
copy-paste it from various BSD-licensed libraries, though (example:
[https://github.com/freebsd/freebsd/blob/master/sys/libkern/b...](https://github.com/freebsd/freebsd/blob/master/sys/libkern/bcmp.c),
but be warned about that _“I don 't believe this is a problem since AFAIK,
objects are not protected at smaller than longword boundaries”_. That likely
is, but may not be true on your platform)

~~~
tedunangst
So the problem here is I may already have a function in my program called
bcmp, which takes no arguments and prints "better consider more possibilities"
to standard output. This is all fine and legal. My program also uses memcmp,
because of course it does. But now calls to memcmp are going to be replaced to
with calls to bcmp, which does not have the same effect at all.

~~~
ComputerGuru
That’s nothing new, though. If you have a memcmp that isn’t memcmp (and don’t
explicitly call a lib-provided memcmp anywhere) and build without libc, your
memcmp will incorrectly be used, too.

MSVC is even more notorious for this kind of issue, silently adding a number
of function calls it assumes the standard library will provide even when your
code doesn’t use the standard library at all.

------
ManDeJan
Hey Andy, will this mean I can try (experimental) zig on risc-v in the near
future? :))

~~~
AndyKelley
llvm9 branch will be merged into master today (as soon as the CI
infrastructure is updated with LLVM 9) and it has basic risc-v support in the
std lib, as well as cross compilation targeting risc-v using glibc and musl.

edit: [me updating the CI
infrastructure]([https://twitter.com/andy_kelley/status/1174769700343074818](https://twitter.com/andy_kelley/status/1174769700343074818))

------
trillic
> Support for asm goto, enabling for example the mainline Linux kernel for
> x86_64 to build with Clang

This is an awesome step!

------
caspervonb
That was fast, has the release cycle changed?

~~~
favorited
LLVM changed their versioning scheme a few releases back (maybe around 3.9 ->
4.0 IIRC?), so major version increases will be more common now. I think it
used to be roughly tied to bitcode compatibility?

Someone who works on LLVM can give a more specific answer, but the gist of it
is we'll see more major version increments now.

~~~
sanxiyn
[http://blog.llvm.org/2016/12/llvms-new-versioning-
scheme.htm...](http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.html)
explains the exact change.

~~~
caspervonb
Ahh thanks!

------
truth_seeker
Good to see LLVM IR becoming the ultimate bridge between Software and Hardware

