#3557: CPU Vector instructions in GHC.Prim
---------------------------------+------------------------------------------
Reporter: guest | Owner: vivian
Type: feature request | Status: new
Priority: normal | Milestone: _|_
Component: Compiler (NCG) | Version: 6.11
Keywords: | Testcase:
Blockedby: | Difficulty: Unknown
Os: Unknown/Multiple | Blocking:
Architecture: Unknown/Multiple | Failure: None/Unknown
---------------------------------+------------------------------------------
Comment(by vivian):
Replying to [comment:5 vivian]:
> So, my plan is to start with adding primOps to GHC.Prim and the compiler
and then follow the code through the compiler to Cmm and the code
generators, making changes as necessary.
Having thought about this more, looked at Cmm and LLVM, and read guest's
comment, it seems a different plan would be better.
Start by adding a vector type to Cmm. Then add platform-specific
'intrinsics'. Then add vector primOps to GHC.Prim.
In Cmm, there are 'Machine-Oppish commands' which seem to relate to FPU-
type operations. The SSE operations use their own 128-bit registers, not
the main CPU registers. Should the vector operations be defined as
'Machine-Oppish' commands since they don't use normal registers, or should
they be given their own register type? It seems that a lot of the vector
operations are almost instances of, e.g., `MO_F_Add Width`. If we had a
`CPUVector Width` type, then we apply `MO_F_Add Width` to each pair of
elements of the `CPUVector`.
There is some tension here, because it would be nice to be able to use
`MO_F_Add` on a pair of vectors, but the `Width` field does not store
enough information to apply the machine op to two vectors.
What about adding vector machine ops, e.g.
{{{
data MachOp
-- Integer operations (insensitive to signed/unsigned)
= MO_Add Width
...
| MO_VI_Add Width Length -- machine op vector int add
...
| MO_VF_Dot Width Length -- machine op vector float dot product
}}}
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3557#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
_______________________________________________
Glasgow-haskell-bugs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
