
On 13/03/14 21:36, Johan Tibell wrote:
On Thu, Mar 13, 2014 at 10:24 PM, Simon Marlow
mailto:marlowsd@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