summaryrefslogtreecommitdiff
path: root/docs
diff options
context:
space:
mode:
authorJohan Tibell <johan.tibell@gmail.com>2014-03-13 09:35:21 +0100
committerJohan Tibell <johan.tibell@gmail.com>2014-03-22 10:32:02 +0100
commit1eece45692fb5d1a5f4ec60c1537f8068237e9c1 (patch)
treeb5d99d52c5a6ab762f9b92dfd0504105122ed62b /docs
parent99ef27913dbe55fa57891bbf97d131e0933733e3 (diff)
downloadhaskell-1eece45692fb5d1a5f4ec60c1537f8068237e9c1.tar.gz
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.
Diffstat (limited to 'docs')
-rw-r--r--docs/users_guide/flags.xml13
1 files changed, 13 insertions, 0 deletions
diff --git a/docs/users_guide/flags.xml b/docs/users_guide/flags.xml
index d932813302..b4febf587b 100644
--- a/docs/users_guide/flags.xml
+++ b/docs/users_guide/flags.xml
@@ -1887,6 +1887,19 @@
<entry><option>-fno-unfolding-use-threshold</option></entry>
</row>
+ <row>
+ <entry><option>-fmax-inline-alloc-size</option>=<replaceable>n</replaceable></entry>
+ <entry>Set the maximum size of inline array allocations to
+ <replaceable>n</replaceable> bytes (default: 128). GHC
+ will allocate non-pinned arrays of statically known size
+ in the current nursery block if they're no bigger than
+ <replaceable>n</replaceable> bytes, ignoring GC overheap.
+ This value should be quite a bit smaller than the block
+ size (typically: 4096).</entry>
+ <entry>dynamic</entry>
+ <entry>-</entry>
+ </row>
+
</tbody>
</tgroup>
</informaltable>