11–20 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.
> 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.
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 compared the difference lies”.
That’s an amount of work that’s independent of the buffer sizes, so it wouldn’t add much, relatively, _if_ the buffers compared are large and the difference (if any) most of the time is near the end of the buffers. I doubt those ifs often hold, though.
> "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]…
*Probably a better word for that
Repo of the Linux kernel built with clang: https://github.com/ClangBuiltLinux/linux
That was fast, has the release cycle changed?
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.
> "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]…
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
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 4.5-ish, and LLVM is adding it in LLVM 9.
*FYI, the name for the thing that GOTO permits which combinations of if and loops doesn't is called "unstructured control flow".
This will break all sorts of code. Often we have things that are const for callers of an API but not necessarily for the implementation of an API. Other cases are where an API should have used const but didn't and then got partly constified, and there are places where you still need to cast away const-ness.
> "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?
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 first release. The only reason clang can compile the Linux kernel is that the clang developers implemented support for the many gcc extensions the Linux kernel uses.
> "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]…
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