#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)
Change History (11)
Changed 3 years ago by
comment:1 follow-up: 3 Changed 3 years ago by
comment:2 Changed 3 years ago by
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 Changed 3 years ago by
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
comment:4 Changed 3 years ago by
Resolution: | → invalid |
---|---|
Status: | new → closed |
comment:5 Changed 3 years ago by
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.
comment:6 Changed 3 years ago by
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
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
Cc: | gmainland added |
---|
comment:9 Changed 10 months ago by
Related Tickets: | → #13878 |
---|
I've opened #13878 to track the lack of SIMD support in the NCG.
comment:10 Changed 10 months ago by
Keywords: | SIMD added |
---|
LLVM code generator has problem too.
My environment is same, and here is the LLVM environment.