Current Status

As of 26 June 2017

Tickets

Status: closed (2 matches)

Ticket	Type	Summary	Priority	Owner
#8033	task	add AVX register support to llvm calling convention	normal
#10286	bug	native code generator: GHC crash at GHC.Prim SIMD vector	normal
Status: new (5 matches)
Ticket	Type	Summary	Priority	Owner
#3557	feature request	CPU Vector instructions in GHC.Prim	normal
#7741	feature request	Add SIMD support to x86/x86_64 NCG	normal	abhir00p
#10648	bug	Some 64-vector SIMD primitives are absolutely useless	normal
#13852	feature request	Can we have more SIMD primops, corresponding to the untapped AVX etc. instructions?	normal
#12412	bug	SIMD things introduce a metric ton of known key things	low

Vector types

Vectors of the following types are implemented: Int32, Int64, Float, and Double. These types and their associated primops can be found in ​`GHC.Prim`.

Fixed and variable sized vectors

For each type, currently only one vector width is implemented, namely the width that is appropriate for SSE2. This means that vectors are currently all 16 bytes in size.

Code generators

Only the LLVM code generator (i.e. -fllvm) is supported. However, work is ​afoot to add support to the NCG as well.

Cmm layer

Our CmmType representation for vectors differs slightly from the proposal. See cmm/CmmType.hs​.

See cmm/CmmMachOp.hs​ for the new vector MachOps.

Core layer

The implementation differs from the proposal in its naming scheme. We wanted to avoid overloading the term "vector," so, e.g., a 4-wide SIMD vector of Float#s is a FloatX4#.

See compiler/prelude/primops.txt.pp​ for the new primops. Not everything in the proposal is implemented, but we do have a useful subset.

Native vector sizes

This is unimplemented. Instead we define a higher-level Multi data family whose instance is platform-dependent. For example, a Multi Int is represented using an Int32X4# on a 32-bit platform, and by a Int64X2# on a 64-bit platform.

ABIs and calling conventions

Integrating variable-sized vectors with GHC's calling convention is a challenge. How many new registers do we add? Do we add registers for each vector type? The correct approach is unclear, so the current implementation passes all SIMD vectors on the stack.

Memory alignment for vectors

The implementation does not attempt to align memory containing SIMD vectors. SIMD vector loads and stores do not assume alignment.

Other resources of interest

• This ghc-devs discussion: ​https://mail.haskell.org/pipermail/ghc-devs/2017-March/013899.html