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

21–30 of 111 posts

Re: LLVM 9.0

#21

Post by pubby »

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 don't see this change breaking the examples you have given. You can always modify non-const objects. What you can't do is modify const objects through a pointer to non-const.

e.g.

    ((char*)"fooo")[0] = 1
is broken code but

    int x = 0;
    int const* y = &x;
    *((int*)y) = 1;
is not.

Re: LLVM 9.0

#23

Post by brackle »

cormacrelf wrote: post #15
KindOne wrote: post #8

Repo of the Linux kernel built with clang: https://github.com/ClangBuiltLinux/linux

"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?

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

Re: LLVM 9.0

#24

Post by cryptonector »

pubby wrote: post #21
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 don't see this change breaking the examples you have given. You can always modify non-const objects. What you can't do is modify const objects through a pointer to non-const. e.g. ((char*)"fooo")[0] = 1 is broken code but int x = 0; int const* y = &x; *((int*)y) = 1; is not.

That's not what I got from the quoted paragraph. I'll have to chase the links to be sure.

Re: LLVM 9.0

#25

Post by steeleduncan »

pjmlp wrote: post #10
MuffinFlavored wrote: post #7

Earlier quoted context omitted.

Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? Are there any downfalls of switching from gcc -> LLVM for kernel compilation? Why might somebody want to stick with gcc, why might somebody want to switch to LLVM?

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?

Re: LLVM 9.0

#26

Post by 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://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/...

Re: LLVM 9.0

#27

Post by tedunangst »

Someone wrote: post #13
nitwit005 wrote: post #5

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

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

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.

Re: LLVM 9.0

#28

Post by AndyKelley »

ManDeJan wrote: post #22

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

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)

Re: LLVM 9.0

#30

Post by The_rationalist »

cesarb wrote: post #19
MuffinFlavored wrote: post #7

Earlier quoted context omitted.

Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? Are there any downfalls of switching from gcc -> LLVM for kernel compilation? Why might somebody want to stick with gcc, why might somebody want to switch to LLVM?

> 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/clang to add support for an attribute.

Post reply on HN