The recent patch to enable soft-float support on PPC64 ("[PowerPC] Refactor soft-float support, and enable PPC64 soft float") has broken Linux kernel builds. We want to avoid floating point in the kernel, but certain files want to be built with vectorisation. One example is arch/powerpc/lib/xor_vmx.c. The command line on these files contains the somewhat convoluted: -msoft-float -mno-altivec -mno-vsx -maltivec -mabi=altivec There are only two files in the kernel that use altivec in C, so perhaps we can come up with a way to solve this in the kernel.
These files use only integer vector operations, correct?
Hi Hal, yes it is RAID5 and RAID6 code that just uses vec_xor, vec_and, vec_cmpgt.
Can you elaborate a bit on what breaks and how it breaks? I am not certain from the description and comments so far whether we need to take any action in LLVM to fix the issue.
(In reply to comment #3) > Can you elaborate a bit on what breaks and how it breaks? I am not certain > from the description and comments so far whether we need to take any action > in LLVM to fix the issue. We currently disable Altivec/VSX support when enabling soft-float. This is because our Altivec lowering promotes various operations to act on v4f32. I don't know why this was done, but I assume it was an arbitrary choice. We'd need to change these promotions (and the associated TableGen patterns, etc.) to work on, say, v4i32 instead. Then we can allow the (non-floating-point) vector instruction selection to proceed even when floating-point support is disabled.
Hello, this issue is blocking compiling the Linux kernel with Clang for ppc. Anything we can do to help move this along?
It seems that this dropped off the radar. Is this still an issue? If not, can we close the PR?
No comments on this for over 2 years other than me asking whether it is still a problem. Closing this as it is likely not a problem and if it is still an issue, please reopen and provide a reproducer.