[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            |        Milestone:
       Component:  Compiler          |          Version:  7.7
      Resolution:                    |         Keywords:
Operating System:  Unknown/Multiple  |     Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown      |       Difficulty:  Unknown
       Test Case:                    |       Blocked By:
        Blocking:                    |  Related Tickets:
-------------------------------------+------------------------------------

Comment (by carter):

 1. changing to "hasSSE2()" will make the engineering for the various
 levels of SIMD and impact on calling convention a teenyt bit simpler
    a.  If we keep "hasSSE1", we'll want to spill Double's to the stack at
 -msse1, and pass the first few in registers on -msse2 or higher, which is
 easy for us to support because we do our stack spills and loads *BEFORE*
 llvm. This is because SSE1 only supports operations on Floats and not
 Doubles. (@gmainland, I see you replied already)
    b. yes, as GHC's SIMD is currently implemented, this is a bug in LLVM
 (or an oversight on our side?!). @Gmainland, could you create a ticket
 with a toy example using GHC head that illustrates it as a bug? (LLVM
 patches that are bug fixes for down stream tools are things we can get
 considered for the 3.3 POINT release). having a ticket and an explicit
 example that hits it would be handy!

 2. The same sort of instruction selection/register problem sort of happens
 once we consider supporting both AVX1 and AVX2!
    a. AVX1 only supports 256bit Float / Double short vector operations,
 its Word / Int operations are 128bit only.
    b.  AVX2 is required for Word / Int operations to be 256bit (except
 when you can encode them as the corresponding Floating point SIMD
 operations). So we really need to sort out a good story here for that
 anyways (which is kinda the same or similar to the sse1 vs sse2 problem,
 Ie many machines have AVX1, all sandy-bridge and ivy-bridge Intel chips,
 and only some cpus have AVX2, the recent Haswell generation)



 3. (this perhaps should be done as a different patch for llvm) Would it be
 worth considering augmenting the number of XMM / YMM used to be'''
 XMM0-7/YMM0-7''' ?  (from current XMM1-6 ).  This would be the same scope
 of change as the x86_32 specific change,  but would mean that roughy LLVM
 3.4 onwards would only work with newer ghcs. (this is true anyways
 actually right? 7.6 and earlier are a bit sloppier in their generated bit
 code, so they dont play nice with newest llvm's, right? ).
   a. This  wouldn't change any Caller side code except for stack spilling,
 and any calle side code aside from a few reads from the stack, right?

 should I re-email the list to make sure other folks are in the loop? It
 sounds like we're already considering changing the x86_32 calling
 convention (albeit in a ghc old and new compatible way), and thats as good
 a time as any to start seriously considering any other calling convention
 changes, even if we test them out using a patched GHC and LLVM first. (i
 don't have the right hardware to run NOFIB for testing such a change
 myself...)

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