[GHC] #8033: add AVX register support to llvm calling convention

[GHC]

#8033: add AVX register support to llvm calling convention
-----------------------------+----------------------------------------------
Reporter:  carter            |          Owner:  carter          
    Type:  task              |         Status:  new             
Priority:  normal            |      Component:  Compiler        
 Version:  7.7               |       Keywords:                  
      Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
 Failure:  None/Unknown      |      Blockedby:                  
Blocking:                    |        Related:                  
-----------------------------+----------------------------------------------

Comment(by carter):

 relatedly, i'm looking at the llvm calling convention spec, and I'm
 noticing / just now realizing that 32bit x86 mode doesn't preclude using
 simd!

 https://github.com/llvm-
 mirror/llvm/blob/master/lib/Target/X86/X86CallingConv.td#L428
 (the ghc calling convention and the associated others)

 So we perhaps could replicate the simd stanzas and add them to 32bit
 calling convention on the llvm side?

 I believe that would have zero impact on any ghc that uses llvm 32bit with
 the current calling convention because ghc manages its own stack spilling,
 and would harmonize simd to be llvm + x86  backend specific but not 64bit
 only (merely leaves the question of the segmenting of various levels of
 SIMD support that the target has, which is needed for using avx / avx2
 correctly anyways, so *shouldnt* change any complexity on our side ).

 Im not going to add that for now, but just throwing the idea out there,
 because as is, for supporting interesting SIMD, we need to have a finer
 grained notion of target going forward *anyways* beyond "is it x86_64" or
 not *Anyways*, and in some sense, those other notions are *orthogonal* to
 32 bit vs 64bit


 If you two favor such a change, i'll add that to the proposed patch.
 (we'll stil have to hash out better sub target info in ghc land, but thats
 separate from making sure the backend has the machinery to support it
 already or not )

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/8033#comment:8>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler