[GHC] #8885: Add inline versions of clone array primops

GHC ghc-devs at haskell.org
Sat Mar 22 10:17:22 UTC 2014


#8885: Add inline versions of clone array primops
-------------------------------------+------------------------------------
        Reporter:  tibbe             |            Owner:  simonmar
            Type:  feature request   |           Status:  patch
        Priority:  normal            |        Milestone:
       Component:  Compiler          |          Version:  7.9
      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 tibbe):

 I've rebased the first three patches, validated them, and submitted them
 as:

 In [changeset:1eece45692fb5d1a5f4ec60c1537f8068237e9c1/ghc]:
 {{{
 commit 1eece45692fb5d1a5f4ec60c1537f8068237e9c1
 Author: Johan Tibell <johan.tibell at gmail.com>
 Date:   Thu Mar 13 09:35:21 2014 +0100

     codeGen: inline allocation optimization for clone array primops

     The inline allocation version is 69% faster than the out-of-line
     version, when cloning an array of 16 unit elements on a 64-bit
     machine.

     Comparing the new and the old primop implementations isn't
     straightforward. The old version had a missing heap check that I
     discovered during the development of the new version. Comparing the
     old and the new version would requiring fixing the old version, which
     in turn means reimplementing the equivalent of MAYBE_CG in StgCmmPrim.

     The inline allocation threshold is configurable via
     -fmax-inline-alloc-size which gives the maximum array size, in bytes,
     to allocate inline. The size does not include the closure header size.

     Allowing the same primop to be either inline or out-of-line has some
     implication for how we lay out heap checks. We always place a heap
     check around out-of-line primops, as they may allocate outside of our
     knowledge. However, for the inline primops we only allow allocation
     via the standard means (i.e. virtHp). Since the clone primops might be
     either inline or out-of-line the heap check layout code now consults
     shouldInlinePrimOp to know whether a primop will be inlined.
 }}}

 This commit does not include `0004-codeGen-cloneArray-use-index-based-for-
 loop-instead-.patch`, which was incorrect.

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


More information about the ghc-tickets mailing list