Should we always inline newByteArray#?

Simon Marlow marlowsd at gmail.com
Thu Mar 13 21:42:03 UTC 2014


On 13/03/14 21:36, Johan Tibell wrote:
> On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow <marlowsd at gmail.com
> <mailto:marlowsd at gmail.com>> wrote:
>
>     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.
>
>
> Sorry for not being clear. We will only do the inline *allocation* if
> the size <= 128 bytes. I'm talking about always inlining the *code*
> (whether it contains a call to allocate or not). In one case we will
> inline a definition reusing the heap check. In the other case we will
> inline a definition that calls allocate.

Oh I see, sorry for misunderstanding.  In that case it's a 
straightforward code size / speed tradeoff.  When a similar case came up 
recently (PAP optimisations) I turned it on for -O2 only.  Someday I'd 
really like to have a -Os that would allow us a bit more control over 
decisions like this.

Cheers,
Simon



More information about the ghc-devs mailing list