native code generator: GHC crash at GHC.Prim SIMD vector

[hkanai]

When compiling attached source file, GHC panics. The following is the error message.

$ ghc -Wall Vec3.hs
[1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o )
ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-unknown-linux):
        Size.intSize W256

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Currently native code generator does not support SIMD operations, and my computer does not support AVX instructions. Therefore ghc cannot compile the source at any case. So I think this bug is not so important.

My system environment.

$ uname -a
Linux think 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux

$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.10.1

$ cat /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     L9300  @ 1.60GHz
stepping        : 6
microcode       : 0x60c
cpu MHz         : 1601.000
cache size      : 6144 KB
physical id     : 0
siblings        : 2
core id         : 0
cpu cores       : 2
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bugs            :
bogomips        : 3193.86
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 23
model name      : Intel(R) Core(TM)2 Duo CPU     L9300  @ 1.60GHz
stepping        : 6
microcode       : 0x60c
cpu MHz         : 1601.000
cache size      : 6144 KB
physical id     : 0
siblings        : 2
core id         : 1
cpu cores       : 2
apicid          : 1
initial apicid  : 1
fpu             : yes
fpu_exception   : yes
cpuid level     : 10
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx lm constant_tsc arch_perfmon pebs bts nopl aperfmperf pni dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm sse4_1 lahf_lm ida dtherm tpr_shadow vnmi flexpriority
bugs            :
bogomips        : 3193.86
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

[hkanai]

LLVM code generator has problem too.

$ ghc -Wall -fllvm -mavx -mavx2 Vec3.hs
[1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o )
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
opt: /tmp/ghc2501_0/ghc2501_2.ll:7:6: error: unexpected type in metadata definition
!0 = metadata !{metadata !"top", i8* null}

My environment is same, and here is the LLVM environment.

$ llvm-as --version
LLVM (http://llvm.org/):
  LLVM version 3.6.0
  Optimized build.
  Built Apr  2 2015 (15:02:32).
  Default target: x86_64-unknown-linux-gnu
  Host CPU: penryn

[carter]

Hello!

1) the SIMD primops in GHC are highly experimental, and they're ONLY supported on the -fllvm backend currently, so YOU WILL get a GHC panic when trying to compile them with the normal backend (this is planned to be fixed at some point, but also requires rethinking what the SIMD api SHOULD be, because writing good SIMD isn't portable between even different micro architectures!)

2) your HOST CPU doesn't support AVX style instructions, so DoubleX4# sized simd values wont be compiled terribly efficiently, because LLVM will (in some fashion) split those DoubleX4# values across two DoubleX2# sized registers.

3) that llvm error about !0 = metadata !{metadata !"top", i8* null} seems like a real bug! I'm going to rope some other folks in to help track that down.

[erikd]

Replying to hkanai:

LLVM version 3.6.0

There's you problem!

The upstream LLVM developers have changed the LLVM IR (Intermediate Repersentation) in 3.6 so that its not possible to easily support llvm 3.4 and 3.6 (and 3.5 had other issues).

Git HEAD currently only supports llvm-3.6 (checked at configure time) and I'm about to propose a version of patch 485dba86d2519c (ticket #10234) for the 7.10 branch taht only allows llvm 3.4

[erikd]

Just to update with a correction to my previous comment, on amd64-linux building from the ghc-7.10 git branch, there are two llvm backend related validation errors with llvm 3.4 and none with llvm-3.5.

My 7.10 patch will therefore only allow llvm-3.5.

[hkanai]

Oh, I did not know the SIMD primops and LLVM backend are such unstable. I will use it with checking implementation status carefully.

Thanks for letting me know.

[carter]

I personally recommend writing your simd in C and using the FFI, but if you wanna use the current simd operations, tread carefully! Good SIMD code requires using custom use of the instructions available on the cpu micro architectures you care about. The current GHC SIMD primops does not expose those in a way that allows peak throughput SIMD.

[bgamari]

I've opened #13878 to track the lack of SIMD support in the NCG.