Re: [Patch,Fortran] PR 42958 - cleanup gfc_call_malloc

[Richard Guenther <richard dot guenther at gmail dot com>]

On Fri, Feb 19, 2010 at 10:54 PM, Tobias Burnus <burnus@net-b.de> wrote:
> Dear all,
>
> gfc_call_malloc is used to allocate memory for temporary variables. The
> trunk version does first a simple overflow check: If the requested size,
> e.g. ?<array-size>*<sizeof(element)>, is negative (-> overflow) then an
> error is printed. For systems with 64bit pointers it does not help and
> for 32bit systems, it is also questionable (and not reliable). Thus,
> this patch removes this check.
>
> Additionally, this patch makes the malloc-success check optional,
> depending on a the new -fcheck=mem check.
>
> I think there is unnecessarily another condition:
> ?size1 = ubound-lbound
> ?size = size1 < 0 ? 0 : size
> ?malloc (MAX(1, size))
> the check whether size is "< 0" is not needed. However, the conditional
> is created at a different place (gfc_trans_create_temp_array) and as
> that function returns "size", it requires some thinking about when one
> can get rid of this conditional.
>
> Build and regtested on x86-64-linux. OK for the trunk?
>
> Tobias
>
> PS: I have not done any performance tests; however, if
> gfc_trans_create_temp_array is called in a deeply nested loop (e.g. when
> the variable is used in a function all), there is some overhead involved
> and as Richard puts it: "the introduced control-flow makes it very hard
> to remove unnecessary temporaries in the middle-end later."

Indeed.  The idea is to implement hosting/sinking of malloc/free pairs
as the Frontend currently isn't able to re-use allocated storage
efficiently for array temporaries generated in loops.  For 450.tonto
we spend 10% of the overall time in malloc/free :/  (it's unfortunately
not possible to avoid the temporary creation without serious
data-flow analysis work - too late for the frontend).

Richard.