clang, sparc: missing compiler command line flags for linux kernel build #40792
Comments
|
For OpenBSD/sparc64 we ran into -mno-fpu being missing when building the kernel. |
EugeneZelenko
added
backend:Sparc
clang:driver
|
@llvm/issue-subscribers-clang-driver |
|
I see in the Sparc GCC options document that : I changed |
|
@arndb, @nickdesaulniers - I'm hitting the following after I turn off the Any ideas what might cause this ? I'd like to get the Linux SPARC LLVM port to completion. |
|
I would recommend you try ld.bfd instead of ld.lld to reduce the number of variables in your build setup compared to the gcc setup. For https://github.com/ClangBuiltLinux, we pretty much ignore sparc now, as there is very little interest in the architecture upstream compared to the other clang supported targets. |
|
The lld support state is similar: the port is quite incomplete. I am also concerned of sparc doing things too differently and lld support would introduce maintenance burden. |
|
actually, if I compile ONLY for 64-bit : I'm getting different errors (regardless of if I use This is happening because ie, no I'll fix that and update here. |
The hope is that we won't introduce maintenance burden since Sparc is in many ways very similar to Mips for example and Mips support is already in and pretty strong. |
|
From a quick look about the various issues in the report: This is already implemented in clang as I don't think clang has any option to set the 64-bit SPARC code model now, but from the assembly output I'm guessing that currently it compiles in a mode corresponding to GCC's 32-bit V8+ ABI extensions is also unsupported by clang right now :( I have no idea what do those options do and I can't find it in GCC's documentation, so no comment on those. As for the instructions, seems like GNU assembler has those two nonstandard aliases for WRPR: God knows why did they decide to place the About LLD, I'm unfamiliar with it and its internals but at least I can confirm that as of now it can only work on very basic use cases, so binutils' LD is still the way to go for SPARC linking needs. |
The OP said above he was building both sparc and sparc64 kernels. So I think the confusion is the fact the options are all clumped together instead of being separated into the options being passed to a sparc kernel vs a sparc64 kernel. |
Please provide a diff. Both *BSD and Linux use this. |
Yep!
They reserve registers from the register allocator (so you can ensure "important" global variables are always in specific registers for fast access) and change the calling convention. We have to implement them per target in llvm; a few other targets already support these, but support is a per architecture job since the flag contains arch specific registers.
Supporting the 32b ARM target linux kernel builds was a similar story... (see some of my commits that mention ARM in LLVM). GAS has some psuedo instructions when operands make sense to be implied, for shorthand, IIUC.
LLD support for sparc linux kernels would be of interest. Perhaps a dedicated bug for that would be worth pursuing if we could get compiler support first. |
Even more so on OpenBSD/sparc64. We'll see if we can hobble along with our binutils 2.17 for now. But pushing for Clang + IAS to mature enough so we can switch to Clang as the system compiler first. |
|
Here are the review tickets for the WRPR and FPU flags:
|
Add two GNU extension forms of wrpr: wrpr %reg, %rd -> wrpr %reg, %g0, %rd wrpr imm, %rd -> wrpr %g0, imm, %rd Note: since the semantics of wrpr %rs1, %rs2/imm, %rd is %rd <- (%rs1 xor %rs2/imm), in case (1) it technically doesn't matter whether the %g0 is placed as the first or second operand, however, I'm placing it as the second operand to match the encoding of GNU as. This fixes the wrpr instruction part of bug #40792 Reviewed By: arsenm Differential Revision: https://reviews.llvm.org/D139535
This adds some SPARC feature flags to clang, for those that we have in common with GCC: -m[no-]fpu -m[no-]fsmuld -m[no-]popc -m[no-]vis -m[no-]vis2 -m[no-]vis3 -m[hard/soft]-quad-float All have the same meanings as GCC's options (https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html). This fixes, among other things, the -mno-fpu part of bug #40792 Reviewed By: nickdesaulniers Differential Revision: https://reviews.llvm.org/D139768
|
@ihiasi It would be good to have further feedback based on testing the latest. |
|
Looking at the Linux kernel Makefile these are the flags for sparc / sparc64 kernel builds.. |
|
@koachan Anything else planned after the recent bits went in? |
From looking at the flags, at least, there's two things that is still missing:
Also, @nickdesaulniers, could you please guide me to how the register allocation flags is implemented in other arches? |
|
commit 287a3be ("[AArch64] Support reserving x1-7 registers.") should be helpful for |
Do you have a diff for implementing the -fcall-used-reg options? |
|
With 18 going out soon, it would be nice to have more feedback. Any other issues building the kernel or other components like glibc. |
Hmm, not yet, unfortunately, will do if there's some free time opening up~
I say that at least when it comes to Linux kernel, as soon as the flags issues have been cleaned up we can try doing a test build or two and see what happens? My feeling is that IAS is still probably missing some instruction/register definitions, but fixing that should be able to be done in parallel with testing on builds w/o IAS. (But then this thread is about compiler flag support so it's probably better to track IAS issues, if any, on a separate thread? I dunno...) |
Or... we could take the Looking into it more, it seems like it's a microoptimization attempt rather than something needed for correctness. Building the kernel (using GCC) with those flags results in a working binary, and since LLVM does not have any support for Also, looking at the Linux kernel port, all LLVM-supported architectures do not use those flags too... What do you think? @brad0 @nickdesaulniers |
|
It would be good to do some archeology in git to find the kernel commit that introduced the usage of that flag. That commit's commit message probably has important information and historical context as to why it was ever added in the first place.
Did you mean without? If so, then kbuild does have |
If it's just essentially a micro-optimization then I tend to agree with you. I am more interested in truly functional issues. Missing bits from IAS and other code building and generation issues. |
|
When that flag was used for aarch64, the entire kernel had its own custom calling convention. I don't see how stealing registers from the register allocator could ever be considered an optimization. |
It seems to date back to the first commit inside git (sparc sparc64), but it's probably even older and the git commit message does not say anything about it.
Yep, should be "without"! Sorry for the typo...
In the 32-bit ABI, %g5 and %g7 is normally reserved, and in the 64-bit ABI, %g7 is the reserved one. On the other hand, the |
Try checking the history trees?
Ah, I'm mixing those two flags up! Then yes, it sounds like the kernel is modifying the default calling convention to potentially have additional registers for register allocation available that aren't reserved in the same way that they are for userspace. Still, it would be helpful to do the archaeology to confirm that that is the case. If so, then |
Linux 2.1.29 is the first kernel release / commit based on this archive. |
|
Wow, so this predates even the full history tree. Ok, thanks for your due diligence; it will be helpful in the kernel discussions. I guess the next thing to do would be to either
It's probably better to start with the general question to the list. I'd use the kernel's MAINTAINERS file to cc:
|
|
So it seems that clang still does not recognize the split L/H inline asm register naming on these functions? It returns a SPARC "twinword" datatype so Any pointers where do I need to look for if I want to implement this? |
Those are called operand modifiers. In LLVM, they are documented here. |
|
@koachan What is the status of building the kernel with the latest and greatest? |
Sorta mixed, I suppose?
|
I'm a kernel maintainer and I can help you with the upstreaming process. I also happen to know the SPARC maintainer in the kernel.
I assume that LLD is going to be replaced with mold in the long term anyway, isn't it? |
|
@koachan Btw, if you have any idea how to fix the LLVM build hanging on the Linux SPARC buildbot, I'd highly appreciate any input. See: https://lab.llvm.org/staging/#/builders/186 Excerpt from one build: |
|
The buildbot is likely out of RAM, which usually happens when using bfd linker. Consider using a different linker (e.g. -DLLVM_USE_LINKER=lld), if appropriate. |
Thanks. I just switched to If that's not enough, I'll add |
I've never heard that and with only ELF support that's not possible. |
Ok, please continue to fix any issues here.
It definitely needs work. But don't worry about LLD just yet. |
Reducing LLVM_PARALLEL_LINK_JOBS might also help. |
I see. I thought that LLD would be replaced in the long-term since Apple is also using their own new linker these days. |
Thank you! I guess I have two questions for now: |
There is a script called This article covers everything you need to know:
Separate to what? Each patch should normally make one logical change.
Just post them to the corresponding mailing list according to |
|
What is the current status building the Linux kernel with Clang as is? |
As far as I can tell, on the LLVM side as of the latest git main:
On the Linux kernel side there's still two little patchsets12 waiting to be upstreamed. Footnotes |
If there are any bits that miscompile with IAS that should be fixed. LLD I wouldn't worry about just yet. Make sure any compilation and code generation issues with Clang / IAS and the other components are fixed first. The patches look good as a start. Not having to disable IAS from the looks of it should be worked on. |
I swear I thought something had been done about handling -Wa options for SPARC. |
Nope, haven't done anything of the sort yet. |
Extended Description
I tried to build the Linux kernel for sparc32 and sparc64. Both work with few changes, but the Makefiles pass a number of options to the compiler that clang does not understand.
In particular, linux-5.1 passes
Removing all of these from the Makefile gets it to compile almost all files, but I'm fairly sure this will not boot because some of the options are in fact required.
The text was updated successfully, but these errors were encountered: