5 ms·
> "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 m
by lpage 7y ago
> "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/784929d0454c4df6a98ef6fbbd1d30a6f71f9c16 https://github.com/llvm/llvm-project/commit/784929d0454c4df6...
[2] https://www.spinics.net/lists/netdev/msg544057.html https://www.spinics.net/lists/netdev/msg544057.html
- colechristensen 7y agoCan 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
- nlewycky 7y agoGOTO 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 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".
- lpage 7y agoPros 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.html https://lists.llvm.org/pipermail/llvm-dev/2017-April/111748.... [2] https://lwn.net/Articles/748074/ https://lwn.net/Articles/748074/ [3] http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html http://lists.llvm.org/pipermail/llvm-dev/2018-October/127239...
- cesarb 7y agoThis is not about "goto", it's about "asm goto", which is a gcc extension which allows inline assembly (itself a gcc extension) to jump to a label outside the inline assembly.
- bumblebritches5 7y agoInline assembly is part of the C11 standard as Asm("assembly goes here")
- mrmonkeyman 7y agoAlso known as "awesome goto".
- drdrey 7y agore: nonlinearity, I believe the word is irreducibility (https://en.wikipedia.org/wiki/Control-flow_graph#Reducibility https://en.wikipedia.org/wiki/Control-flow_graph#Reducibilit...)
- MuffinFlavored 7y agoDoes 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?
- cesarb 7y ago> 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 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.
- The_rationalist 7y agoInteresting 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.
- chc 7y agoWho in the world would do that rather than just supporting both compilers?
- The_rationalist 7y agoYou don't seems to understand that extensions/attributes can have a usefulness that far outweight cross compiler compatibility? Type of reasons: Performance critical; Security; Expressivity; Each of them can be a necessary reason. E.g "polymorphism" in C through transparent unions