Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

LLVM 9.0

lists.llvm.org

Post reply on HN
Print view View original

61–70 of 111 posts

Re: LLVM 9.0

#61

Post by mlindner »

jcranmer wrote: post #31
brynet wrote: post #26

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 consi…

> This change only happened due to corporate pressure, and was done without considering the impact towards the open source community. FWIW, it's worth noting that only OpenBSD has this stance, and it was brought up a few times on the mailing list. The general summary is that "every lawyer we've had look into this issue has said that OpenBSD's fears about the patent licensing clauses are FUD, and OpenBSD has provided…

Thanks, can you give some links to that discussion?

Re: LLVM 9.0

#62

Post by mlindner »

rurban wrote: post #58
cryptonector wrote: post #18

> 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:…

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, an…

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

Re: LLVM 9.0

#63

Post by est31 »

pjmlp wrote: post #45
est31 wrote: post #40

Earlier quoted context omitted.

The biggest issue of fuchsia isn't its license, it's rather the design choice to allow proprietary driver blobs. Linux, for the exception of a few blobs here and there, rejects such an idea. In other words, the question is less about license and more about attitude / tolerance for proprietary extensions/tooling. The main power that an open source maintainer has is the design of the codebase and what to accept inside,…

Google has already achieved that with Project Treble by the way.

But they had to pay for the project. For others it might not have been economic to do it. Also, in fact there were Android-custom abstraction layers before project Treble, and the Treble abstraction layer is not around the device drivers but the entire kernel including the drivers.

Re: LLVM 9.0

#64

Post by spacepinball »

The_rationalist wrote: post #30
cesarb wrote: post #19

Earlier quoted context omitted.

> Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? It was already possible to compile the kernel with clang/llvm. But a few releases ago, the Linux kernel dropped support for being built with older compilers which did not have support for the "asm goto" gcc extension. The Linux kernel has always targeted gcc exclusively, and makes heavy use of gcc extensions since its very…

Interesting so this means that if someone really want llvm to support an extension (say a C attribute) that GCC supports, then you "just" have to make a contribution to the Linux kernel that use the gcc attribute and that is a minimum useful. Then LLVM will prioritize the support of said attribute. As such, hardcore developers might become new Linux contributors just as an Indirect (but effective) way to force LLVM/c…

Rational indeed

Re: LLVM 9.0

#65

Post by sanxiyn »

The_rationalist wrote: post #30
cesarb wrote: post #19

Earlier quoted context omitted.

> Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? It was already possible to compile the kernel with clang/llvm. But a few releases ago, the Linux kernel dropped support for being built with older compilers which did not have support for the "asm goto" gcc extension. The Linux kernel has always targeted gcc exclusively, and makes heavy use of gcc extensions since its very…

Interesting so this means that if someone really want llvm to support an extension (say a C attribute) that GCC supports, then you "just" have to make a contribution to the Linux kernel that use the gcc attribute and that is a minimum useful. Then LLVM will prioritize the support of said attribute. As such, hardcore developers might become new Linux contributors just as an Indirect (but effective) way to force LLVM/c…

Yes, this is in fact a viable strategy. Source: I contributed a few GCC extension in Clang forced by Linux kernel.

Re: LLVM 9.0

#66

Post by sanxiyn »

rurban wrote: post #58
cryptonector wrote: post #18

> 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:…

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, an…

> This helps only artificial benchmarks and will hurt everybody.

Any source of this claim? As I understand, on SPEC 2006 lib call optimizations make 5% improvement with GCC, the least artificial benchmark among SPEC 2006.

Re: LLVM 9.0

#67

Post by sanxiyn »

favorited wrote: post #16
caspervonb wrote: post #12

That was fast, has the release cycle changed?

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.

http://blog.llvm.org/2016/12/llvms-new-versioning-scheme.htm... explains the exact change.

Re: LLVM 9.0

#68

Post by favorited »

mlindner wrote: post #61
jcranmer wrote: post #31

Earlier quoted context omitted.

> This change only happened due to corporate pressure, and was done without considering the impact towards the open source community. FWIW, it's worth noting that only OpenBSD has this stance, and it was brought up a few times on the mailing list. The general summary is that "every lawyer we've had look into this issue has said that OpenBSD's fears about the patent licensing clauses are FUD, and OpenBSD has provided…

Thanks, can you give some links to that discussion?

It was, as you might guess, a series of very long discussions over several years:

Initial RFC: https://lists.llvm.org/pipermail/llvm-dev/2015-October/09153...

RFC 2: http://lists.llvm.org/pipermail/llvm-dev/2016-September/1047...

RFC 3: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112142.h...

Update: http://lists.llvm.org/pipermail/llvm-dev/2018-October/126991...

OpenBSD objection subthread: http://lists.llvm.org/pipermail/llvm-dev/2017-April/112300.h...

Re: LLVM 9.0

#69

Post by ndesaulniers »

steeleduncan wrote: post #25
pjmlp wrote: post #10

Earlier quoted context omitted.

Mainstream yes. Android has moved to clang for quite a while now, the Linux kernel is the only GPL piece left.

Fuschia seems to be non-GPL. Are Google trying to remove GPL entirely from Android?

I am removing GCC/binutils from Android.

I wrote: https://android.googlesource.com/platform/prebuilts/clang/ho...

It has nothing to do with GPL. It has everything to do with Google having 50+ LLVM developers and 0 GCC/binutils developers.

Re: LLVM 9.0

#70

Post by ndesaulniers »

cryptonector wrote: post #18

> 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:…

So I've been bitten by this twice already, including just today.

1. This was the last bug preventing us from booting a MIPS Linux kernel. 2. An out of tree MediaTek display driver in Android was causing a kernel panic.

To be clear, this is explicitly undefined behavior in C. But this optimization to me feels like semantics from C bleeding into LLVM IR a little.

Post reply on HN