On 13/03/14 20:39, Johan Tibell wrote:
Hi all,
After some refactoring of the StgCmmPrim, it's now possible to have both
an inline and an out-of-line (in PrimOps.cmm) version of the same
primop. Very soon (#8876) we'll have both an inline and an out-of-line
version of newByteArray#. The inline version is used when the array size
is statically known and commons up the allocation with the normal heap
check.
The reason to have both versions is that we don't want to increase code
size to much (by inlining a primop which implementation is large) unless
we know that there's a benefit in doing so. However, the newByteArray#
implementation is one function call (to allocate) followed by three
stores (to the closure header). Perhaps, that's small enough to always
inline? It would save one function call for each call to newByteArray#.
Anyone have any thoughts on whether always inlining would be a good idea?
It's a bad idea for large arrays (>= 3k), because when allocated via
allocate() these arrays get a blocked marked with BF_LARGE that doesn't
get copied during GC.
It might be a good idea for arrays less than this size (including the
header). It's a bad idea if the size isn't statically known, though.
Cheers,
Simon
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs