[GHC] #5208: Unroll array copy/clone primops in the native and LLVM code generators
GHC
cvs-ghc at haskell.org
Wed Jun 8 22:42:24 CEST 2011
#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 dterei):
So it looks fine, here are some comments though:
'''0002-Unroll-memcpy-in-the-X86-backend.patch'''
* '-- 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
* 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.
* Should 'maxInlineSizeThreshold' be shared rather than duplicated?
'''0001-Use-the-new-memcpy-memmove-memset-MachOps.patch'''
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?
'''0001-Add-test-for-unrolling-memcpy-memset-in-the-x86-back.patch'''
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 64,65,66,67 and
alignments 1,2,4,8. The unroll code is fairly tricky and so we want an
extensive test case.
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.
--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/5208#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler
More information about the Glasgow-haskell-bugs
mailing list