Opened 3 years ago

Closed 3 years ago

Last modified 5 months ago

#10286 closed bug (invalid)

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

Reported by: hkanai Owned by:
Priority: normal Milestone:
Component: Compiler Version: 7.10.1
Keywords: SIMD Cc: gmainland
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: #13878 Differential Rev(s):
Wiki Page:

Description

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:

Attachments (1)

Vec3.hs (2.2 KB) - added by hkanai 3 years ago.

Download all attachments as: .zip

Change History (11)

Changed 3 years ago by hkanai

Attachment: Vec3.hs added

comment:1 Changed 3 years ago by 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

comment:2 Changed 3 years ago by 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.

comment:3 in reply to:  1 Changed 3 years ago by 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

Last edited 3 years ago by erikd (previous) (diff)

comment:4 Changed 3 years ago by erikd

Resolution: invalid
Status: newclosed

comment:5 Changed 3 years ago by 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.

Last edited 3 years ago by erikd (previous) (diff)

comment:6 Changed 3 years ago by 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.

comment:7 Changed 3 years ago by 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.

comment:8 Changed 3 years ago by simonpj

Cc: gmainland added

comment:9 Changed 5 months ago by bgamari

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

comment:10 Changed 5 months ago by bgamari

Keywords: SIMD added
Note: See TracTickets for help on using tickets.