GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2024-02-19T08:23:52Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/24222256-bit floating-point SIMD primitives unnecessarily require `-mavx2`2024-02-19T08:23:52Zarata, mizuki256-bit floating-point SIMD primitives unnecessarily require `-mavx2`## Summary
When using 256-bit floating-point SIMD primitives (i.e. `FloatX8#` or `DoubleX4#`), GHC requires `-mavx2`. `-mavx` should be sufficient.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE Un...## Summary
When using 256-bit floating-point SIMD primitives (i.e. `FloatX8#` or `DoubleX4#`), GHC requires `-mavx2`. `-mavx` should be sufficient.
## Steps to reproduce
```haskell
-- Test.hs
{-# LANGUAGE MagicHash #-}
{-# LANGUAGE UnboxedTuples #-}
import GHC.Exts
main = do
let (# x0, x1, x2, x3 #) = unpackDoubleX4# (negateDoubleX4# (packDoubleX4# (# 0.0##, 1.1##, 2.2##, 3.3## #)))
print (D# x0, D# x1, D# x2, D# x3)
```
```
$ _build/stage1/bin/ghc -fllvm -mavx Test.hs
[1 of 2] Compiling Main ( Test.hs, Test.o )
<no location info>: error:
sorry! (unimplemented feature or known bug)
GHC version 9.9.20231124:
256-bit wide integer SIMD vector instructions require at least -mavx2.
$ _build/stage1/bin/ghc -fllvm -mavx2 Test.hs
[1 of 2] Compiling Main ( Test.hs, Test.o )
[2 of 2] Linking Test
```
## Expected behavior
`ghc -fllvm -mavx Test.hs` should compile.
## Environment
* GHC version used: 9.9.20231124 (34d863153155284c3e389d258f454490c205b58f)
* Operating System: Ubuntu 22.04
* System Architecture: x86-64arata, mizukiarata, mizukihttps://gitlab.haskell.org/ghc/ghc/-/issues/24073Turn on `-msse4.2` by default on hosts which support it.2023-10-10T14:08:15ZOleg GrenrusTurn on `-msse4.2` by default on hosts which support it.The motivation for this is that ordinary user probably doesn't know that they will benefit from enabling this flag (and e.g. leave `popCount`, `countLeadingZeros` instructions unused), e.g. `cabal install my-new-program` is slower.
... ...The motivation for this is that ordinary user probably doesn't know that they will benefit from enabling this flag (and e.g. leave `popCount`, `countLeadingZeros` instructions unused), e.g. `cabal install my-new-program` is slower.
... and same can be argued for other instruction sets (which have been around for some quite time).
We probably need explicit `-mno-sse4.2` etc flags *to disable* instruction sets, maybe some "disable all instruction sets" flag as well. This will be needed when compiling some to be distributed binaries.
Alternatively the packages will be polluted with explicit flags, like in https://github.com/haskell-unordered-containers/unordered-containers/pull/483https://gitlab.haskell.org/ghc/ghc/-/issues/23870LLVM 13+ doesn't recognize `-stack-alignment` option2023-08-25T19:32:16Zarata, mizukiLLVM 13+ doesn't recognize `-stack-alignment` option## Summary
When using `-mavx` with recent LLVM backend (LLVM 13 or later), LLVM optimizer fails with
```
opt-13: Unknown command line argument '-stack-alignment=32'. Try: 'opt-13 --help'
opt-13: Did you mean '--stackrealign=32'?
```
...## Summary
When using `-mavx` with recent LLVM backend (LLVM 13 or later), LLVM optimizer fails with
```
opt-13: Unknown command line argument '-stack-alignment=32'. Try: 'opt-13 --help'
opt-13: Did you mean '--stackrealign=32'?
```
## Steps to reproduce
```
$ cat > Hello.hs
main = putStrLn "Hello world!"
$ ghc-9.6.2 -pgmlo opt-13 -pgmlc llc-13 -fllvm -mavx Hello.hs
[1 of 2] Compiling Main ( Hello.hs, Hello.o )
opt-13: Unknown command line argument '-stack-alignment=32'. Try: 'opt-13 --help'
opt-13: Did you mean '--stackrealign=32'?
<no location info>: error:
`opt-13' failed in phase `LLVM Optimiser'. (Exit code: 1)
```
## Expected behavior
The program should compile and link without problems.
## Environment
* GHC version used: 9.6.2 and master
* Operating System: Linux
* System Architecture: x86_649.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/23410Support 128-bit SIMD on AArch64 via LLVM backend2023-08-22T19:14:37Zarata, mizukiSupport 128-bit SIMD on AArch64 via LLVM backendCurrently, SIMD primitives are only available on x86(\_64). It would be nice to extend SIMD support to AArch64.
The initial step would be supporting 128-bit width SIMD with ASIMD (NEON) via LLVM backend. Support via NCG or consideration...Currently, SIMD primitives are only available on x86(\_64). It would be nice to extend SIMD support to AArch64.
The initial step would be supporting 128-bit width SIMD with ASIMD (NEON) via LLVM backend. Support via NCG or consideration of SVE can follow.
I opened a MR at !10456.Andreas KlebingerAndreas Klebingerhttps://gitlab.haskell.org/ghc/ghc/-/issues/22297Cmm types don't account for registers which can be used for several purposes2023-01-31T21:34:02Zsheafsam.derbyshire@gmail.comCmm types don't account for registers which can be used for several purposesAs noted in #22296, SIMD registers can be used to hold different kinds of values, for example `xmm1` can hold a `DoubleX2#`, a `FloatX4#`, a `Word32X4#`, an `Int16x8#`, etc.
Currently, in Cmm Lint, we expect to be able to compute the ty...As noted in #22296, SIMD registers can be used to hold different kinds of values, for example `xmm1` can hold a `DoubleX2#`, a `FloatX4#`, a `Word32X4#`, an `Int16x8#`, etc.
Currently, in Cmm Lint, we expect to be able to compute the type of a register, but we consider a 128-bit wide floating-point register distinct from a 128-bit wide integer register. This means that Cmm Lint fails when one tries to use `xmm1` except for the one "blessed" purpose (which currently is a vector register for 4 32-bit integers (signed or unsigned)).
We should instead have a different notion which allows registers to serve multiple different purposes.sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22296Miscompilation & Cmm Lint failure with SIMD vectors2022-12-13T09:31:01Zsheafsam.derbyshire@gmail.comMiscompilation & Cmm Lint failure with SIMD vectorsThe following program fails Cmm Lint:
```haskell
{-# language MagicHash, UnboxedTuples, UnboxedSums #-}
module Main ( main ) where
import GHC.Exts
import GHC.Int
foo :: Int32X4# -> Integer
foo i32x4 =
case unpackInt32X4# i32x4 of
...The following program fails Cmm Lint:
```haskell
{-# language MagicHash, UnboxedTuples, UnboxedSums #-}
module Main ( main ) where
import GHC.Exts
import GHC.Int
foo :: Int32X4# -> Integer
foo i32x4 =
case unpackInt32X4# i32x4 of
(# i1, i2, i3, i4 #) ->
let
s = sum $ map fromIntegral
[ I32# i1, I32# i2, I32# i3, I32# i4 ]
in s
main :: IO ()
main = do
print ( foo ( broadcastInt32X4# ( intToInt32# 1# ) ) )
```
```
Cmm lint error:
in basic block c1EB
in MachOp application:
%MO_UU_Conv_W64_W32(1 :: W32)
op is expecting: [W64]
arguments provide: [I32]
Program was:
{offset
c1Fg: // global
_s1Ew::P64 = R1;
if ((old + 0) - <highSp> < SpLim) (likely: False) goto c1Fh; else goto c1Fi;
c1Fi: // global
Hp = Hp + 48;
if (Hp > HpLim) (likely: False) goto c1Fk; else goto c1Fj;
c1Fk: // global
HpAlloc = 48;
goto c1Fh;
c1Fh: // global
R1 = _s1Ew::P64;
call (stg_gc_enter_1)(R1) args: 8, res: 0, upd: 8;
c1Fj: // global
(_c1EA::I64) = call "ccall" arg hints: [PtrHint,
PtrHint] result hints: [PtrHint] newCAF(BaseReg, _s1Ew::P64);
if (_c1EA::I64 == 0) goto c1EC; else goto c1EB;
c1EC: // global
call (I64[_s1Ew::P64])() args: 8, res: 0, upd: 8;
c1EB: // global
I64[(old + 24)] = stg_bh_upd_frame_info;
I64[(old + 16)] = _c1EA::I64;
_c1EE::Ix4V128 = <0 :: W32, 0 :: W32, 0 :: W32, 0 :: W32>;
_c1EF::Ix4V128 = %MO_V_Insert_4_W32(_c1EE::Ix4V128,
%MO_UU_Conv_W64_W32(1 :: W32), 0 :: W32);
_c1EG::Ix4V128 = %MO_V_Insert_4_W32(_c1EF::Ix4V128,
%MO_UU_Conv_W64_W32(1 :: W32), 1 :: W32);
_c1EH::Ix4V128 = %MO_V_Insert_4_W32(_c1EG::Ix4V128,
%MO_UU_Conv_W64_W32(1 :: W32), 2 :: W32);
_c1EI::Ix4V128 = %MO_V_Insert_4_W32(_c1EH::Ix4V128,
%MO_UU_Conv_W64_W32(1 :: W32), 3 :: W32);
_c1ED::Ix4V128 = _c1EI::Ix4V128;
_s1Ef::Ix4V128 = _c1ED::Ix4V128;
_s1Eh::I32 = %MO_SS_Conv_W32_W64(%MO_V_Extract_4_W32(_s1Ef::Ix4V128,
0 :: W32));
_s1Ei::I32 = %MO_SS_Conv_W32_W64(%MO_V_Extract_4_W32(_s1Ef::Ix4V128,
1 :: W32));
_s1Ej::I32 = %MO_SS_Conv_W32_W64(%MO_V_Extract_4_W32(_s1Ef::Ix4V128,
2 :: W32));
_s1Ek::I32 = %MO_SS_Conv_W32_W64(%MO_V_Extract_4_W32(_s1Ef::Ix4V128,
3 :: W32));
_s1Ek::I32 = _s1Ek::I32;
_s1Ej::I32 = _s1Ej::I32;
_s1Ei::I32 = _s1Ei::I32;
_s1Eh::I32 = _s1Eh::I32;
I64[Hp - 40] = sat_s1Ev_info;
I32[Hp - 24] = _s1Eh::I32;
I32[Hp - 20] = _s1Ei::I32;
I32[Hp - 16] = _s1Ej::I32;
I32[Hp - 12] = _s1Ek::I32;
_c1EL::P64 = Hp - 40;
I64[Hp - 8] = sat_s1El_info;
_c1F9::P64 = Hp - 8;
R3 = _c1EL::P64;
R2 = _c1F9::P64;
R1 = $_closure;
call stg_ap_pp_fast(R3, R2, R1) args: 24, res: 0, upd: 24;
}
```
It seems that the vector broadcast and unpack instructions end up emitting conversion instructions at incorrect types?
Turning off Cmm Lint, I get the following error from LLVM:
```
opt: /run/user/1000/ghc230199_0/ghc_1.ll:494:18: error: invalid cast opcode for cast from 'i32' to 'i32'
%ln1K6 = trunc i32 1 to i32
^
```sheafsam.derbyshire@gmail.comsheafsam.derbyshire@gmail.comhttps://gitlab.haskell.org/ghc/ghc/-/issues/22187ghc panic using SIMD types with unboxed sums2022-12-13T09:31:01ZDavid Orion Girardoghc panic using SIMD types with unboxed sums```haskell
{-# language MagicHash,UnboxedSums #-}
module Test where
import GHC.Prim
foo :: (# Int8X16# | () #) -> ()
foo _ = ()
```
building with `-fllvm` yields:
```
<no location info>: error:
panic! (the 'impossible' happened)
...```haskell
{-# language MagicHash,UnboxedSums #-}
module Test where
import GHC.Prim
foo :: (# Int8X16# | () #) -> ()
foo _ = ()
```
building with `-fllvm` yields:
```
<no location info>: error:
panic! (the 'impossible' happened)
GHC version 9.4.2:
primRepSlot
No slot for VecRep
Call stack:
CallStack (from HasCallStack):
callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic
pprPanic, called at compiler/GHC/Types/RepType.hs:329:27 in ghc:GHC.Types.RepType
```
This appears to happen for all SIMD types.
Other combinations of SIMD types (eg in an unboxed tuple) are working fine.9.6.1https://gitlab.haskell.org/ghc/ghc/-/issues/20214panic when trying to load module with SIMD vector operations into GHCi2022-02-25T01:26:48ZJakob Brünkerpanic when trying to load module with SIMD vector operations into GHCi## Steps to reproduce
Load the following module into GHCi:
```haskell
{-# LANGUAGE UnboxedTuples, MagicHash #-}
import GHC.Exts
main = print $ case unpackDoubleX2# (broadcastDoubleX2# 4.4##) of
(# a, b #) -> (D# a, D# b)
```
this r...## Steps to reproduce
Load the following module into GHCi:
```haskell
{-# LANGUAGE UnboxedTuples, MagicHash #-}
import GHC.Exts
main = print $ case unpackDoubleX2# (broadcastDoubleX2# 4.4##) of
(# a, b #) -> (D# a, D# b)
```
this results in
```
panic! (the 'impossible' happened)
GHC version 9.3.20210802:
GHC.StgToByteCode.findPushSeq
```
The same thing happens when trying to define `main` inside of GHCi.
## Expected behavior
Ideally, GHCi should be able to load the module without issue (except for, possibly, a warning that it won't be able to run code containing SIMD operations), and only once the user actually attempts to evaluate an expression that relies on SIMD operations should a runtime error occur.
If that's not possible, then, when loading the module, a more helpful error message should appear, somewhat similar to the one that appears when trying to compile the module with ghc:
```
ghc: sorry! (unimplemented feature or known bug)
GHC version 9.3.20210802:
SIMD vector instructions require the LLVM back-end.
Please use -fllvm.
```
## Environment
* GHC version used: `9.3.20210802`
Optional:
* Operating System: Arch Linux
* System Architecture: x86_64https://gitlab.haskell.org/ghc/ghc/-/issues/12412SIMD things introduce a metric ton of known key things2021-03-31T13:30:06ZBen GamariSIMD things introduce a metric ton of known key thingsIn #12357 we were looking at reducing the number of entries in the `knownKeyNames`. This has the potential to improve compiler performance since this set of things is always present in the original name cache, which is often referred to....In #12357 we were looking at reducing the number of entries in the `knownKeyNames`. This has the potential to improve compiler performance since this set of things is always present in the original name cache, which is often referred to.
#12357 reduced the number of elements in `knownKeyNames` from 2017 to 1834. Not a bad improvement. That being said, the SIMD operations introduce nearly four times that number. These include things like `readWord64OffAddrAsWord64X2#`, `indexInt16OffAddrAsInt16X16#`, and `remInt16X16#`. All in all these operations constitute nearly a third of the known key names.
I'm not really sure what can be done about this, but I thought it should be noted.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 8.0.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"SIMD things introduce a metric ton of known key things","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"8.0.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"In #12357 we were looking at reducing the number of entries in the `knownKeyNames`. This has the potential to improve compiler performance since this set of things is always present in the original name cache, which is often referred to.\r\n\r\n#12357 reduced the number of elements in `knownKeyNames` from 2017 to 1834. Not a bad improvement. That being said, the SIMD operations introduce nearly four times that number. These include things like `readWord64OffAddrAsWord64X2#`, `indexInt16OffAddrAsInt16X16#`, and `remInt16X16#`. All in all these operations constitute nearly a third of the known key names.\r\n\r\nI'm not really sure what can be done about this, but I thought it should be noted.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/16927simd001 fails in profasm way2020-01-23T18:32:58ZBen Gamarisimd001 fails in profasm wayThe `simd001` (among other `simd*` tests) fails in the `profasm` way.The `simd001` (among other `simd*` tests) fails in the `profasm` way.8.10.1Ben GamariBen Gamarihttps://gitlab.haskell.org/ghc/ghc/-/issues/16971Is SIMD vector code dead?2019-07-25T21:46:26ZRichard Eisenbergrae@richarde.devIs SIMD vector code dead?Some time ago, we removed the vectoriser from GHC, as it was dead code. But I still see an awful lot of vector stuff floating about. (For example, in `RuntimeRep`, `PrimRep`, `PrimOpVecCat`, primops, etc.) Is all this dead? I was trying ...Some time ago, we removed the vectoriser from GHC, as it was dead code. But I still see an awful lot of vector stuff floating about. (For example, in `RuntimeRep`, `PrimRep`, `PrimOpVecCat`, primops, etc.) Is all this dead? I was trying to figure out where these vectors are finally consumed (generated into code). The closest I found was `vecElemInjectCast` and `vecElemProjectCast`. However, these seem to be triggered by primops like `VecBroadcastOp`... but I don't see where a `VecBroadcastOp` comes from.
I'm poking around in areas I don't know at all, so I may be very wrong, and I'd love to learn more about this all.
However, if this code is dead, I propose we either
1. Remove the dead code; or
2. Document this carefully, with a Note. The Note should say why we haven't removed the dead code (presumably, because we wish to resurrect it later), a plausible route to reviving the code from the dead (I wouldn't ask for a timeline, just a plausible story), and should be referred to from every place that's dead. (There are a lot of them!)
I'm happy to do either of these tasks.https://gitlab.haskell.org/ghc/ghc/-/issues/8033add AVX register support to llvm calling convention2019-07-07T18:46:45ZCarter Schonwaldadd AVX register support to llvm calling conventionGHC HEAD currently has support for SSE 128bit registers (XMM), and it would be very little additional work to add 256bit AVX2 operations (when available) PROVIDED that the llvm calling convention for ghc is modified to support them when ...GHC HEAD currently has support for SSE 128bit registers (XMM), and it would be very little additional work to add 256bit AVX2 operations (when available) PROVIDED that the llvm calling convention for ghc is modified to support them when available
the current definition in LLVM can be seen here https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X86/X86CallingConv.td\#L279-L291
the current definition is
```
def CC_X86_64_GHC : CallingConv<[
// Promote i8/i16/i32 arguments to i64.
CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,
// Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim
CCIfType<[i64],
CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>,
// Pass in STG registers: F1, F2, F3, F4, D1, D2
CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
CCIfSubtarget<"hasSSE1()",
CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>,
]>;
```
I believe the update should read
```
def CC_X86_64_GHC : CallingConv<[
// Promote i8/i16/i32 arguments to i64.
CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,
// Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim
CCIfType<[i64],
CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>,
// Pass in STG registers for floats,doubles and 128bit simd vectors
CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],
CCIfSubtarget<"hasSSE1()",
CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>,
// Pass in STG registers for first 7 256bit simd vectors
CCIfType<[v32i8, v16i16, v8i32, v4i64, v8f32, v4f64],
CCIfSubtarget<"hasAVX()",
CCAssignToReg<[YMM0, YMM1, YMM2, YMM3,
YMM4, YMM5, YMM6]>>>
]>;
```
Note that this is FULLY backwards compatible with current GHC, it merely means that we can have 256bit simd values if we so choose.
if I get the go ahead from y'all, i'm happy to see about getting that patch into llvm
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 7.7 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"add AVX register support to llvm calling convention","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.7","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"FeatureRequest","description":"GHC HEAD currently has support for SSE 128bit registers (XMM), and it would be very little additional work to add 256bit AVX2 operations (when available) PROVIDED that the llvm calling convention for ghc is modified to support them when available\r\n\r\nthe current definition in LLVM can be seen here https://github.com/llvm-mirror/llvm/blob/master/lib/Target/X86/X86CallingConv.td#L279-L291\r\n\r\nthe current definition is \r\n{{{\r\n\r\ndef CC_X86_64_GHC : CallingConv<[\r\n // Promote i8/i16/i32 arguments to i64.\r\n CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,\r\n\r\n // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim\r\n CCIfType<[i64],\r\n CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>,\r\n\r\n // Pass in STG registers: F1, F2, F3, F4, D1, D2\r\n CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],\r\n CCIfSubtarget<\"hasSSE1()\",\r\n CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>,\r\n\r\n\r\n]>;\r\n\r\n\r\n}}}\r\n\r\n\r\nI believe the update should read\r\n\r\n{{{\r\n\r\ndef CC_X86_64_GHC : CallingConv<[\r\n // Promote i8/i16/i32 arguments to i64.\r\n CCIfType<[i8, i16, i32], CCPromoteToType<i64>>,\r\n\r\n // Pass in STG registers: Base, Sp, Hp, R1, R2, R3, R4, R5, R6, SpLim\r\n CCIfType<[i64],\r\n CCAssignToReg<[R13, RBP, R12, RBX, R14, RSI, RDI, R8, R9, R15]>>,\r\n\r\n // Pass in STG registers for floats,doubles and 128bit simd vectors\r\n CCIfType<[f32, f64, v16i8, v8i16, v4i32, v2i64, v4f32, v2f64],\r\n CCIfSubtarget<\"hasSSE1()\",\r\n CCAssignToReg<[XMM1, XMM2, XMM3, XMM4, XMM5, XMM6]>>>,\r\n\r\n// Pass in STG registers for first 7 256bit simd vectors\r\nCCIfType<[v32i8, v16i16, v8i32, v4i64, v8f32, v4f64],\r\n CCIfSubtarget<\"hasAVX()\",\r\n CCAssignToReg<[YMM0, YMM1, YMM2, YMM3,\r\n YMM4, YMM5, YMM6]>>>\r\n\r\n]>;\r\n\r\n\r\n}}}\r\n\r\nNote that this is FULLY backwards compatible with current GHC, it merely means that we can have 256bit simd values if we so choose. \r\n\r\nif I get the go ahead from y'all, i'm happy to see about getting that patch into llvm","type_of_failure":"OtherFailure","blocking":[]} -->8.4.1Carter SchonwaldCarter Schonwaldhttps://gitlab.haskell.org/ghc/ghc/-/issues/10286native code generator: GHC crash at GHC.Prim SIMD vector2019-07-07T18:36:45Zhkanainative code generator: GHC crash at GHC.Prim SIMD vectorWhen 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_6...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:
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 7.10.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"native code generator: GHC crash at GHC.Prim SIMD vector","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"7.10.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When compiling attached source file, GHC panics. The following is the error message.\r\n\r\n{{{\r\n$ ghc -Wall Vec3.hs\r\n[1 of 1] Compiling Data.Vector.Vec3 ( Vec3.hs, Vec3.o )\r\nghc: panic! (the 'impossible' happened)\r\n (GHC version 7.10.1 for x86_64-unknown-linux):\r\n Size.intSize W256\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nCurrently 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.\r\n\r\nMy system environment.\r\n{{{\r\n$ uname -a\r\nLinux think 3.19.2-1-ARCH #1 SMP PREEMPT Wed Mar 18 16:21:02 CET 2015 x86_64 GNU/Linux\r\n\r\n$ ghc --version\r\nThe Glorious Glasgow Haskell Compilation System, version 7.10.1\r\n\r\n$ cat /proc/cpuinfo\r\nprocessor : 0\r\nvendor_id : GenuineIntel\r\ncpu family : 6\r\nmodel : 23\r\nmodel name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz\r\nstepping : 6\r\nmicrocode : 0x60c\r\ncpu MHz : 1601.000\r\ncache size : 6144 KB\r\nphysical id : 0\r\nsiblings : 2\r\ncore id : 0\r\ncpu cores : 2\r\napicid : 0\r\ninitial apicid : 0\r\nfpu : yes\r\nfpu_exception : yes\r\ncpuid level : 10\r\nwp : yes\r\nflags : 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\r\nbugs :\r\nbogomips : 3193.86\r\nclflush size : 64\r\ncache_alignment : 64\r\naddress sizes : 36 bits physical, 48 bits virtual\r\npower management:\r\n\r\nprocessor : 1\r\nvendor_id : GenuineIntel\r\ncpu family : 6\r\nmodel : 23\r\nmodel name : Intel(R) Core(TM)2 Duo CPU L9300 @ 1.60GHz\r\nstepping : 6\r\nmicrocode : 0x60c\r\ncpu MHz : 1601.000\r\ncache size : 6144 KB\r\nphysical id : 0\r\nsiblings : 2\r\ncore id : 1\r\ncpu cores : 2\r\napicid : 1\r\ninitial apicid : 1\r\nfpu : yes\r\nfpu_exception : yes\r\ncpuid level : 10\r\nwp : yes\r\nflags : 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\r\nbugs :\r\nbogomips : 3193.86\r\nclflush size : 64\r\ncache_alignment : 64\r\naddress sizes : 36 bits physical, 48 bits virtual\r\npower management:\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->