[patch, fortran] Fix PR 87352, far too many deallocations

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[patch, fortran] Fix PR 87352, far too many deallocations

Thomas Koenig-6
Hello world,

the attached patch attempts to fix PR 87352, a 7/8/9 regression (where
there were far too many deallocations in a derived type containing
allocatable arrays) by making sure that no component is finalized more
than once.

This seemed to be a safer, and simpler, approach to me than to try
to change where, and when double finalization might occur and
when it might be safe to remove it.

This might also cure PR 84487 but, of course, SPEC is closed source,
so I cannot check.

@Jeremy: Can you confirm that this fixes the excessive compile time
and code size issue for you?

OK for trunk and backporting?

Regards

        Thomas

2019-03-31  Thomas Koenig  <[hidden email]>

        PR fortran/87352
        * gfortran.h (gfc_component): Add finalized field.
        * class.c (finalize_component): If the component is already
        finalized, return early.  Set component->finalized on exit.

2019-03-31  Thomas Koenig  <[hidden email]>

        PR fortran/87352
        * gfortran.dg/finalize_28.f90: Adjust count of __builtin_free.
        * gfortran.dg/finalize_33.f90: Likewise.
        * gfortran.dg/finalize_34.f90: New test.
Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] Fix PR 87352, far too many deallocations

Jeremy Sanders
Dear Thomas

On 31/03/2019 18:10, Thomas Koenig wrote:

> @Jeremy: Can you confirm that this fixes the excessive compile time
> and code size issue for you?

The patch fixes for me the large problem which was the N^2 number of
deallocations. The compile time speed problem is also fixed. Thanks for
that!

However, I think there is a 2nd problem (maybe caused by the 1st commit
referenced by the bug), where large object files are produced. If I
compile the 1st test case, testcomb.f90, on the bug (not the 2nd one),
the object file is still massive (200MB).

I think this is caused by very large .zero outputs in the assembler file
that go into __def_init_XXX_type.

There is also very large stack usage. I think these are associated with
initialisation of the datatypes. It seems the code creates the object
with the allocation on the stack, marks the subarrays as unallocated,
then memcpys this into the allocated object. As the objects can be
large, this leads to large stack usage.

Best wishes

Jeremy

Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] Fix PR 87352, far too many deallocations

Thomas Koenig-6
Am 01.04.19 um 11:19 schrieb Jeremy Sanders:

> Dear Thomas
>
> On 31/03/2019 18:10, Thomas Koenig wrote:
>
>> @Jeremy: Can you confirm that this fixes the excessive compile time
>> and code size issue for you?
>
> The patch fixes for me the large problem which was the N^2 number of
> deallocations. The compile time speed problem is also fixed. Thanks for
> that!

Good, so at least one part of the problem is solved (or will be as soon
as this patch is committed).

> However, I think there is a 2nd problem (maybe caused by the 1st commit
> referenced by the bug), where large object files are produced.

This sounds like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 .

> There is also very large stack usage. I think these are associated with
> initialisation of the datatypes. It seems the code creates the object
> with the allocation on the stack, marks the subarrays as unallocated,
> then memcpys this into the allocated object. As the objects can be
> large, this leads to large stack usage.

That might be a consequence, yes.  This is not really my area of
expertise, but I will at least take a look.

Regards

        Thomas

Reply | Threaded
Open this post in threaded view
|

Re: [patch, fortran] Fix PR 87352, far too many deallocations

Paul Richard Thomas
Hi Thomas,

One quick way of reducing the problem would be to set _def_init to
NULL if there is nothing to initialize.

I have been meaning to tackle this myself but just have not had the
time of late. Day time work is keeping me too busy :-(

Paul

On Mon, 1 Apr 2019 at 19:56, Thomas Koenig <[hidden email]> wrote:

>
> Am 01.04.19 um 11:19 schrieb Jeremy Sanders:
> > Dear Thomas
> >
> > On 31/03/2019 18:10, Thomas Koenig wrote:
> >
> >> @Jeremy: Can you confirm that this fixes the excessive compile time
> >> and code size issue for you?
> >
> > The patch fixes for me the large problem which was the N^2 number of
> > deallocations. The compile time speed problem is also fixed. Thanks for
> > that!
>
> Good, so at least one part of the problem is solved (or will be as soon
> as this patch is committed).
>
> > However, I think there is a 2nd problem (maybe caused by the 1st commit
> > referenced by the bug), where large object files are produced.
>
> This sounds like https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 .
>
> > There is also very large stack usage. I think these are associated with
> > initialisation of the datatypes. It seems the code creates the object
> > with the allocation on the stack, marks the subarrays as unallocated,
> > then memcpys this into the allocated object. As the objects can be
> > large, this leads to large stack usage.
>
> That might be a consequence, yes.  This is not really my area of
> expertise, but I will at least take a look.
>
> Regards
>
>         Thomas
>


--
"If you can't explain it simply, you don't understand it well enough"
- Albert Einstein
Reply | Threaded
Open this post in threaded view
|

Re: *ping* [patch, fortran] Fix PR 87352, far too many deallocations

Steve Kargl
In reply to this post by Thomas Koenig-6
On Sat, Apr 06, 2019 at 04:49:55PM +0200, Thomas Koenig wrote:

> Am 31.03.19 um 18:16 schrieb Thomas Koenig:
> > Am 31.03.19 um 18:10 schrieb Thomas Koenig:
> >> Hello world,
> >>
> >> the attached patch
> >
> > Now really attached.
> >
>
> Ping?

OK.

--
Steve