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

31–40 of 111 posts

Re: LLVM 9.0

#31

Post by jcranmer »

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 no legal opinions to back its claims up."

Re: LLVM 9.0

#32

Post by pjmlp »

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?

Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX.

In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source.

Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how WebAssembly + WebGL/WebGPU happen to evolve (depending on how Google and Apple feel like driving it).

Then the anti-GPL crowd might remember the days that they got GCC, GNU and the Linux kernel, or maybe not.

Although for many of us that deal daily with commercial software that is kind of irrelevant anyway.

Re: LLVM 9.0

#33

Post by soulofmischief »

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?

They're following in Apple's stead, I guess.

Re: LLVM 9.0

#34

Post by moefh »

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

I think it will break a lot less code than you think.

The C standard has a subtlety with regards to const in that it allows you to (for example) cast away the const-ness of a pointer and use it to write to it, as long as the original memory was not const (i.e., it was gratuitously cast to const). That's used by a lot of code, and LLVM still respects that.

This optimization (AFAIK) only removes stores that are disallowed by the standard, which is when the memory itself you're trying to store to was actually declared const. This would most likely cause a crash anyway, the memory would in most cases be inside a read-only segment. The bug report mentioned is from code inside a kernel, not from a normal executable that would be loaded with proper memory protection (like making read-only sections actually read-only), which is probably why the code worked without the optimization.

See the example in[1]:

- The function g casts away the const to write to the pointed memory, the generated assembly does what you'd expect (it contains a store).

- The function f tries to write to memory the compiler knows is actually const, clang optimizes the store away. Trying to actually write there would crash if the program was loaded in a normal OS, since the memory is inside a read-only segment.

[1] https://godbolt.org/z/as3Mh5

Re: LLVM 9.0

#35

Post by d33 »

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

I guess the question is: will it silently optimize them away or will it be a compile error to use such expressions?

Re: LLVM 9.0

#36

Post by lpage »

nlewycky wrote: post #17
colechristensen wrote: post #14

Earlier quoted context omitted.

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

GOTO was supported in LLVM from the beginning. The new feature is ASM GOTO. An ASM block is opaque to the compiler, and the compiler treats it similarly to a function call. A called function may contain control flow internal to itself, but can't cause control flow to happen in the caller. ASM GOTO is a new syntax for informing the compiler that this inline ASM may contain a GOTO to a given label. GCC added it around…

Pros of asm goto: it's useful for introducing low overhead tracing and debugging abstractions. Tracepoints in the Linux kernel are one example [1]. It's also used for implementing certain Meltdown/Spectre mitigations [2].

Cons of asm goto: as parent points out, asm blocks are largely opaque to the compiler, which stands in the way of optimization. Control flow analysis can't take into account internal jumps, and for GCC at least, every asm goto block gets flagged as volatile. That disables whole classes of optimization.

Unless you're relying on hardware-specific instructions that the compiler doesn't know about or expose as an intrinsic, there's always an alternative to asm goto. That said, those alternatives might prove more expensive than the loss of optimizations precluded by the use of asm goto [2].

The pros/cons of including asm goto in clang were discussed in [3].

[1] https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748....

[2] https://lwn.net/Articles/748074/

[3] http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239...

Re: LLVM 9.0

#37

Post by riscy »

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…

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...

Re: LLVM 9.0

#38

Post by simcop2387 »

riscy wrote: post #37
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…

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

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.

Re: LLVM 9.0

#39

Post by brynet »

riscy wrote: post #37
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…

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

No, it doesn't. The aforementioned concerns have nothing to do with the GPL license.

https://github.com/llvm/llvm-project/blob/master/llvm/LICENS...

> .. "If you combine or link compiled forms of this Software with software that is licensed under the GPLv2 .. "

Re: LLVM 9.0

#40

Post by est31 »

pjmlp wrote: post #32
steeleduncan wrote: post #25

Earlier quoted context omitted.

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

Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX. In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source. Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how We…

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, not the power to litigate a copyleft license. The more it cooperates with proprietary software, the more likely proprietary software can establish itself and restrict user freedoms.
Post reply on HN