Looks like related to -msoft-float for llvm.ppc.altivec.vcmpgtsb

Reduced source and command line to reproduce:

$ cat t.c
#include <altivec.h>
typedef unsigned int __kernel_size_t;
typedef __kernel_size_t size_t;
typedef unsigned char u8;
typedef vector signed char unative_t;
#define NBYTES(x) ((vector signed char) {x,x,x,x, x,x,x,x, x,x,x,x, x,x,x,x})
#define NSIZE sizeof(unative_t)
static inline unative_t SHLBYTE(unative_t v)
{
return vec_add(v,v);
}
static inline unative_t MASK(unative_t v)
{
unative_t zv = NBYTES(0);
return (unative_t)vec_cmpgt(zv, v);
}
void raid6_altivec1_gen_syndrome_real(int disks, size_t bytes, void **ptrs)
{
u8 **dptr = (u8 **)ptrs;
u8 *p, q;
int d, z, z0;
unative_t wd0, wq0, wp0, w10, w20;
unative_t x1d = NBYTES(0x1d);
z0 = disks - 3; / Highest data disk /
p = dptr[z0+1]; / XOR parity /
q = dptr[z0+2]; / RS syndrome /
for ( d = 0 ; d < bytes ; d += NSIZE1 ) {
wq0 = wp0 = *(unative_t )&dptr[z0][d+0NSIZE];
for ( z = z0-1 ; z >= 0 ; z-- ) {
wd0 = *(unative_t )&dptr[z][d+0NSIZE];
wp0 = vec_xor(wp0, wd0);
w20 = MASK(wq0);
w10 = SHLBYTE(wq0);
w20 = vec_and(w20, x1d);
w10 = vec_xor(w10, w20);
wq0 = vec_xor(w10, wd0);
}
*(unative_t )&p[d+NSIZE0] = wp0;
*(unative_t )&q[d+NSIZE0] = wq0;
}
}

$ clang -S t.c -msoft-float
SplitVectorResult #​0: t71: v16i8 = llvm.ppc.altivec.vcmpgtsb TargetConstant:i64<4823>, t68, t69

fatal error: error in backend: Do not know how to split the result of this operator!

clang-7: error: clang frontend command failed with exit code 70 (use -v to see invocation)
clang version 8.0.0
Target: powerpc64le-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/jji/wyvern/build/bin
clang-7: note: diagnostic msg: PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace, preprocessed source, and associated run script.
clang-7: note: diagnostic msg:

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-7: note: diagnostic msg: /tmp/t-1d562d.c
clang-7: note: diagnostic msg: /tmp/t-1d562d.sh
clang-7: note: diagnostic msg:

$ clang -S t.c

Further reduced:

$ cat reduced.ll
; ModuleID = 'bugpoint-reduced-simplified.ll'
source_filename = "t.c"
target datalayout = "e-m:e-i64:64-n32:64"
target triple = "powerpc64le-unknown-linux-gnu"

; Function Attrs: noinline nounwind optnone
define internal <16 x i8> @​0(<16 x i8>) #​0 {
%2 = call <16 x i8> @​llvm.ppc.altivec.vcmpgtsb(<16 x i8> undef, <16 x i8> undef) #​2
ret <16 x i8> %2
}

; Function Attrs: nounwind readnone
declare <16 x i8> @​llvm.ppc.altivec.vcmpgtsb(<16 x i8>, <16 x i8>) #​1

attributes #​0 = { noinline nounwind optnone "correctly-rounded-divide-sqrt-fp-math"="false" "disable-tail-calls"="false" "less-precise-fpmad"="false" "no-frame-pointer-elim"="true" "no-frame-pointer-elim-non-leaf" "no-infs-fp-math"="false" "no-jump-tables"="false" "no-nans-fp-math"="false" "no-signed-zeros-fp-math"="false" "no-trapping-math"="false" "stack-protector-buffer-size"="8" "target-cpu"="ppc64le" "target-features"="+altivec,+bpermd,+crypto,+direct-move,+extdiv,+htm,+power8-vector,+vsx,-power9-vector,-qpx" "unsafe-fp-math"="false" }
attributes #​1 = { nounwind readnone }
attributes #​2 = { nounwind }

!llvm.ident = !{#0}

!​0 = !{!"clang version 8.0.0 "}
$ llc reduced.ll
$ llc -mattr=-hard-float reduced.ll
SplitVectorResult #​0: t3: v16i8 = llvm.ppc.altivec.vcmpgtsb TargetConstant:i64<4823>, undef:v16i8, undef:v16i8

LLVM ERROR: Do not know how to split the result of this operator!

This is actually duplicate of #30525 ,
I think currently a limitation.

When we enabled soft-float for ppc64, we chose to disable altivec!

http://llvm.org/viewvc/llvm-project?view=revision&revision=283060

This change enables soft-float for PowerPC64, and also makes soft-float disable
all vector instruction sets for both 32-bit and 64-bit modes. This latter part
is necessary because the PPC backend canonicalizes many Altivec vector types to
floating-point types, and so soft-float breaks scalarization support for many
operations. Both for embedded targets and for operating-system kernels desiring
soft-float support, it seems reasonable that disabling hardware floating-point
also disables vector instructions (embedded targets without hardware floating
point support are unlikely to have Altivec, etc. and operating system kernels
desiring not to use floating-point registers to lower syscall cost are unlikely
to want to use vector registers either). If someone needs this to work, we'll
need to change the fact that we promote many Altivec operations to act on
v4f32. To make it possible to disable Altivec when soft-float is enabled,
hardware floating-point support needs to be expressed as a positive feature,
like the others, and not a negative feature, because target features cannot
have dependencies on the disabling of some other feature. So +soft-float has
now become -hard-float.