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

81–90 of 111 posts

Re: LLVM 9.0

#81

Post by ComputerGuru »

ndesaulniers wrote: post #76
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?

No but it's complicated. We shipped ARM64 clang built linux kernels with clang-4.0 in Google Pixel 2. x86_64 was buildable up until ~4.20 Linux kernel release. (so we could build 4.4, 4.9, 4.14, and 4.19 LTS x86_64 kernels pre-clang-9). The x86_64 maintainers required the use of CONFIG_JUMP_LABEL/asm goto in the 4.20 kernel release IIRC. Certain configs and drivers needed compiler fixes. Pretty soon we'll be moving A…

I want to say Intel was advertising compiling the kernel with ICC around 2009 or so. (ICC and I parted ways around 2010).

Re: LLVM 9.0

#82

Post by [deleted] »

tedunangst wrote: post #56
Someone wrote: post #51

Earlier quoted context omitted.

http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#notewo... : ”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 eas…

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.

[deleted]

Re: LLVM 9.0

#83

Post by ndesaulniers »

brackle wrote: post #23
cormacrelf wrote: post #15

Earlier quoted context omitted.

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

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

Re: LLVM 9.0

#84

Post by ComputerGuru »

tedunangst wrote: post #56
Someone wrote: post #51

Earlier quoted context omitted.

http://releases.llvm.org/9.0.0/docs/ReleaseNotes.html#notewo... : ”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 eas…

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.

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.

Re: LLVM 9.0

#85

Post by pjmlp »

ndesaulniers wrote: post #80
pjmlp wrote: post #79

Earlier quoted context omitted.

Maybe some of them could be reassigned to the NDK tooling then. I and other NDK users have several ideas of what is missing versus Java/Kotlin.

A lot of my teammates focus on LLVM for Android, including the NDK, which redistributes AOSP LLVM. > what is missing versus Java/Kotlin. I'd be happy to pass on feedback, though as worded I'm not sure if you're referring to language features or what exactly?

As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others:

An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls.

Which by the way, given the whole security theme on Android, means more insecure code than if we had those C++ APIs to start with.

Have one shot libraries like Oboe actually be part of NDK and not in another github repo with uncertain future versus the Android platform.

For basic stuff like reading files (using the platform codecs e.g. BitmapFactory, now SAF as well), asking permissions, calling Java from C++, it would be nice if all NDK users wouldn't be force to keep writing those from scratch as rite of passage.

Actually provide build infrastructure to create NDK libraries that can be shared across Android projects, instead of forcing us to somehow cram library and header files into AAR packages while having build scripts extract them for correct placement where cmake and ndk-build expect to find them. cdep never went anywhere, while conan and vcpkg aren't the right answer when many NDK libraries need Java code to come along due to JNI wrappers for like 90% of Android APIs.

Android Studio networking debugger support, currently only supported for networking calls done in Java/Kotlin code.

Easier CMake support for multiple libraries on our projects, which is found lacking versus how easy it is on ndk-build.

As mentioned, these are just a couple of issues that we keep mentioning, always getting some kind of "thanks for the feedback, we will look into it". Just like the NDK status talk at Google IO 2019.

From the outside it doesn't look like NDK is that staffed with engineers, more like a 20% project where a little bit is done every year, like how long it took to fix the header files, adding minimal C++ support to Android Studio, or settling into CMake as the future build system.

EDIT: Almost forgot this one, fix the regressions regarding missing GCC features in clang (Android NDK tracker used to have a couple of them listed).

Re: LLVM 9.0

#86

Post by trasz »

ndesaulniers wrote: post #73
shmerl wrote: post #41

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

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

Fun fact - they do work fine... under FreeBSD :-)

Re: LLVM 9.0

#87

Post by ndesaulniers »

pjmlp wrote: post #85
ndesaulniers wrote: post #80

Earlier quoted context omitted.

A lot of my teammates focus on LLVM for Android, including the NDK, which redistributes AOSP LLVM. > what is missing versus Java/Kotlin. I'd be happy to pass on feedback, though as worded I'm not sure if you're referring to language features or what exactly?

As mentioned already a couple of times with online discussions with Dan and AMA on Reddit, from me and others: An NDK version of Android JetPack/AndroidX, for starters proper C++ API, instead of forcing everyone to code 90's style, each re-creating their own C++ wrappers for the Android C++ APIs exposed as C function calls. Which by the way, given the whole security theme on Android, means more insecure code than if…

Thanks for the feedback, we will look into it. :P

I'm happy to pass these along to Dan and your comment is easy for me to link to, but I don't know why you're suggesting Google move LLVM compiler engineers to work on NDK, which is more of a userspace C++ framework for third party applications to interface with the Android platform. Kind of feels orthogonal to this thread which is about the llvm 9.0 release.

> fix the regressions regarding missing GCC features in clang (Android NDK tracker used to have a couple of them listed).

Now that sounds more like work for Android LLVM engineers, but it sounds like the list is removed? Could you elaborate and point me to some? (Assume anything you claim in a response I'll just ask for a link)

* EDIT * (it seems I can't reply further)

Thanks for the links. I'll pass on both links as feedback and follow up on the state of those two LLVM reported regressions.

Re: LLVM 9.0

#88

Post by [deleted] »

trasz wrote: post #86
ndesaulniers wrote: post #73

Earlier quoted context omitted.

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

Fun fact - they do work fine... under FreeBSD :-)

[deleted]

Re: LLVM 9.0

#89

Post by qalmakka »

ndesaulniers wrote: post #73
shmerl wrote: post #41

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

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

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

Re: LLVM 9.0

#90

Post by ndesaulniers »

qalmakka wrote: post #89
ndesaulniers wrote: post #73

Earlier quoted context omitted.

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

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

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.
Post reply on HN