71–80 of 111 posts
> 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.
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?
Yes, there are still some stability issues though. Phoronix benchmarked the Linux kernel built with Clang/LLVM against GCC recently: https://www.phoronix.com/scan.php?page=article&item=clang-li...
And Phoronix didn't send me any reports; I reached out to Michael and he said he'll send them to me next time he tries.
Meanwhile, Mesa developers merged ACO compiler for AMDGPU, as the future replacement for llvm.
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?
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?
Repo of the Linux kernel built with clang: https://github.com/ClangBuiltLinux/linux
Come check out our once-every-two-weeks public meeting!
> "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... [2]…
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?
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 Android and ChromeOS' arm32 kernels over to Clang as well. CONFIG_FUNCTION_TRACER makes the compiler emit __gnu_mcount_nc calls with a non-standard calling convention just on arm32. You should have seen the Apple reviewer's reaction to the LLVM patch implementing support in LLVM for that!
There's also traces of code in the kernel that suggest it was once build-able with ICC at one point. The code looks broken to me and I suspect it doesn't work. That said, if anyone knows anyone compiling the Linux kernel with ICC, I'd love to get in touch.
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…
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…
Why does it work with gcc?
Then again, all x86_64 processors support sse2, so I'm not surprised that Clang at -mno-sse2 doesn't work better. There's numerous bugs filed against Clang where it crashes when -mno-sse2 is set, but double precision floating point is used.
(I've spent almost all of this week debugging this, and working with CrOS and AMD engineers on this. It's not clear to me at this point whether the 16B-stack-alignment ABI change was well intentioned or a stroke of luck).
Earlier quoted context omitted.
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.
I and other NDK users have several ideas of what is missing versus Java/Kotlin.
Earlier quoted context omitted.
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.
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.
> 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?