[GHC] #5208: Unroll array copy/clone primops in the native and LLVM code generators

[GHC]

#5208: Unroll array copy/clone primops in the native and LLVM code generators
---------------------------------+------------------------------------------
    Reporter:  tibbe             |        Owner:              
        Type:  feature request   |       Status:  patch       
    Priority:  normal            |    Milestone:              
   Component:  Compiler          |      Version:  7.1         
    Keywords:                    |     Testcase:              
   Blockedby:                    |   Difficulty:              
          Os:  Unknown/Multiple  |     Blocking:              
Architecture:  Unknown/Multiple  |      Failure:  None/Unknown
---------------------------------+------------------------------------------

Comment(by tibbe):

 Thanks for reviewing!

 Replying to [comment:7 dterei]:
 >  '-- TODO: Add movabs instruction and support 64-bit sets.' - Can this
 be done now rather than later? It doesn't seem like it should take very
 long. Also I think once you have this done you should be able to unify the
 go functions of memcpy and memset

 The only reason I haven't done so already is that I don't know how to add
 a new instruction. If someone could give some pointers to all the places
 that need to be updated after adding a new instruction and whether I need
 to do something special for 64-bit only instructions I can take a stab at
 it.

 >  By saying add the movabs instruction I assume you want to change the
 memset function to initially store the value to set into a register and
 then mov that register into each of the memory slots. With this change you
 could also have memset handle the case where the value to be set is an
 expression other than a literal.

 Storing the value in a register is necessary as the mov instructions don't
 take 64-bit immediates.

 >  Should 'maxInlineSizeThreshold' be shared rather than duplicated?

 Probably. I will make it a top-level constant for now. Ideally each
 architecture should have its own limit and I'd like to see a common place
 to but architecture specific configuration. The memcpy unrolling
 optimization should ideally be written once and reused on all
 architectures. This requires that we abstract over move instructions and
 the like. This is what LLVM does. It significantly reduces implementation
 effort.

 > Looks fine but would it be worthwhile handling the alignment number in
 the 'emitMemmoveCall', 'emitMemcpyCall' and 'emitMemsetCall' functions
 themselves rather than passing it in as argument?

 I did it this way on purpose as I'd like it to be possible to use the
 `CallishMachOp`s even when the memory isn't aligned. I think this makes
 them more generally useful in GHC.

 > I think this testing method works well. I think you should test when the
 alignment is 8 though as well as 4. Also maybe try to cover a few more
 cases by using some different sizes and alignments. So create the arrays
 at size 71 but then test a few times using sizes say 1,64,65,66,67,71 and
 alignments 1,2,4,8. The unroll code is fairly tricky and so we want an
 extensive test case.

 I'll try to improve the test case this weekend.

 > I'll be happy to help out with any of these points when I have time.
 Other than extending the test case though I would be happy pushing it to
 head as it stands.

 Here's what I suggest: I'll work on improving the tests and fix the minor
 things. The bigger things (like movabs) are additional optimizations on
 top of the current ones so I suggest we save those for separate patches.

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