[PATCH] Implement malloc/free hoisting from loops (PR21046 and friends)

[Richard Guenther]

On Tue, May 11, 2010 at 6:30 AM, Xinliang David Li <davidxl@google.com> wrote:
> On Mon, May 10, 2010 at 8:21 PM, Mark Mitchell <mark@codesourcery.com> wrote:
>> Richard Guenther wrote:
>>
>>> This adds the ability to hoist/sink malloc/free pairs out of loops in
>>> case the size of the allocation is loop-invariant.  This helps
>>> in cases where the Fortran frontend inserts array temporary allocations
>>> inside loops (which happens to cost around 4% performance in 465.tonto).
>>
>> Nice idea.  I don't have a comment on the patch, but the optimization
>> itself would certainly seem beneficial to some programs.
>>
>> I never quite understand the optimization rules for built-ins in GCC.
>> When we know that we are dealing with BUILT_IN_MALLOC, are we allowed to
>> assume that the user has not overridden malloc with their own definition
>> which has side-effects other than the usual ones?

When we see BUILT_IN_MALLOC we assume we have a C89 conformant
implementation.  It's like with any other builtin that could be overridden
by the user - we require -fno-builtin-* if the override is not conformant.
[It's a different story if we just see attribute malloc - that doesn't tell us
that there is a malloc-like function, it just tells something about alias
guarantees of the return value].  So yes - implicitly asked - C++ new/delete
is not covered by this optimization.  We would need a way to
identify these, like with a new attribute or builtin (but we had the
malloc attribute discussion for ::new again and again and we seem to be
still worried about strange user overrides ...)

> Things can get wrong when user provided malloc gets inlined into
> caller functions by cross module inlining. Another area that can get

It can't get more wrong than with moving the call.

> wrong when user provides malloc definition, some other internal
> supporting functions may also get exposed to the user level (e.g.
> tuning APIs). Such functions have hidden dependency with malloc
> routine which may not be modelled properly by the compiler.

If they interfere with the malloc semantics the compiler assumes
they should either be not exposed or the builtin disabled.  Thus,
it's nothing I am worrying about.

Richard.

> David
>
>
>> --
>> Mark Mitchell
>> CodeSourcery
>> mark@codesourcery.com
>> (650) 331-3385 x713
>>
>