Quuxplusone / LLVMBugzillaTest

0 stars 0 forks source link

llvm.ppc.altivec.vcmpgtsb Do not know how to split the result of this operator #37860

Open Quuxplusone opened 6 years ago

Quuxplusone commented 6 years ago
Bugzilla Link PR38887
Status NEW
Importance P enhancement
Reported by Joel Stanley (joel@jms.id.au)
Reported on 2018-09-10 06:38:07 -0700
Last modified on 2018-10-21 04:37:11 -0700
Version trunk
Hardware PC Linux
CC jji@us.ibm.com, llvm-bugs@lists.llvm.org
Fixed by commit(s)
Attachments altivec1-2a11c5.c.gz (800367 bytes, application/gzip)
altivec1-2a11c5.sh (5987 bytes, application/x-shellscript)
Blocks
Blocked by
See also
Created attachment 20857
Preprocessed source

Running clang trunk on ppc64le, building the ppc64le Linux kernel fails when
attempting to build lib/raid6/altivec1.c

SplitVectorResult #0: t196: v16i8 = llvm.ppc.altivec.vcmpgtsb
TargetConstant:i64<4823>, t146, t195

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

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

Attached altivec1-2a11c5.c.gz (800367 bytes, application/gzip): Preprocessed source

Quuxplusone commented 6 years ago

Attached altivec1-2a11c5.sh (5987 bytes, application/x-shellscript): run script

Quuxplusone commented 6 years ago
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 += NSIZE*1 ) {
                wq0 = wp0 = *(unative_t *)&dptr[z0][d+0*NSIZE];
                for ( z = z0-1 ; z >= 0 ; z-- ) {
                        wd0 = *(unative_t *)&dptr[z][d+0*NSIZE];
                        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+NSIZE*0] = wp0;
                *(unative_t *)&q[d+NSIZE*0] = 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
Quuxplusone commented 6 years ago
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!
Quuxplusone commented 6 years ago
This is actually duplicate of https://bugs.llvm.org/show_bug.cgi?id=31177,
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.