Inner functions & -pg

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

Inner functions & -pg

Salvatore Filippone-3
Hi folks,
I have been looking at some profiling data about one of my applications,
and I have noticed that there is a rather erratic behaviour whenever I have
a subroutine that CONTAINs another subroutine; sometimes I get the profiler
(gprof to be precise) printing out the outer subroutine name, sometimes it
shows data about the inner subroutine but with a completely different name.
My impression is that this behaviour is on gfortran's side, because I tried
taking one of those CONTAINed subroutines and made it external, and it
showed with its correct name.
How is this supposed to work, if it is supposed to work at all?
Does it warrant opening a bug report?
Opinions welcome
Salvatore
Reply | Threaded
Open this post in threaded view
|

Re: Inner functions & -pg

Steve Kargl
On Fri, Oct 11, 2019 at 05:15:55PM +0100, Salvatore Filippone wrote:

> I have been looking at some profiling data about one of my applications,
> and I have noticed that there is a rather erratic behaviour whenever I have
> a subroutine that CONTAINs another subroutine; sometimes I get the profiler
> (gprof to be precise) printing out the outer subroutine name, sometimes it
> shows data about the inner subroutine but with a completely different name.
> My impression is that this behaviour is on gfortran's side, because I tried
> taking one of those CONTAINed subroutines and made it external, and it
> showed with its correct name.
> How is this supposed to work, if it is supposed to work at all?
> Does it warrant opening a bug report?
> Opinions welcome

Does the size of the contained subroutine affect
the results?  AFAIU, gfortran will inline contained
subprograms if the routine is small.  This might
affect the profiling.

--
Steve
Reply | Threaded
Open this post in threaded view
|

Re: Inner functions & -pg

Salvatore Filippone-3
The contained subroutines are large, I  doubt inlining went into effect;
and in any case, why would this apply to one subroutine and not to a second
one, more or less the same size?
Anyway, I will try to cut a self-contained test case (which will take some
time)
Thanks
Salvatore

On Fri, Oct 11, 2019 at 5:46 PM Steve Kargl <
[hidden email]> wrote:

> On Fri, Oct 11, 2019 at 05:15:55PM +0100, Salvatore Filippone wrote:
> > I have been looking at some profiling data about one of my applications,
> > and I have noticed that there is a rather erratic behaviour whenever I
> have
> > a subroutine that CONTAINs another subroutine; sometimes I get the
> profiler
> > (gprof to be precise) printing out the outer subroutine name, sometimes
> it
> > shows data about the inner subroutine but with a completely different
> name.
> > My impression is that this behaviour is on gfortran's side, because I
> tried
> > taking one of those CONTAINed subroutines and made it external, and it
> > showed with its correct name.
> > How is this supposed to work, if it is supposed to work at all?
> > Does it warrant opening a bug report?
> > Opinions welcome
>
> Does the size of the contained subroutine affect
> the results?  AFAIU, gfortran will inline contained
> subprograms if the routine is small.  This might
> affect the profiling.
>
> --
> Steve
>
Reply | Threaded
Open this post in threaded view
|

Re: Inner functions & -pg

Janne Blomqvist-3
On Sat, Oct 12, 2019 at 12:22 PM Salvatore Filippone
<[hidden email]> wrote:
>
> The contained subroutines are large, I  doubt inlining went into effect;
> and in any case, why would this apply to one subroutine and not to a second
> one, more or less the same size?

Procedures which are called from only one location are always(?)
inlined, regardless of size.


--
Janne Blomqvist
Reply | Threaded
Open this post in threaded view
|

Re: Inner functions & -pg

Salvatore Filippone-3
Does "from only one location" mean from only one other subroutine or from
only one statement?
Because in this case the container routine calls the internal in two
different points.
Moreover, if it is inlined, then it should show up under the name of the
caller  routine, right?
Anyway, I'll cut a test case  as time allows.
Salvatore

On Sat, Oct 12, 2019 at 1:09 PM Janne Blomqvist <[hidden email]>
wrote:

> On Sat, Oct 12, 2019 at 12:22 PM Salvatore Filippone
> <[hidden email]> wrote:
> >
> > The contained subroutines are large, I  doubt inlining went into effect;
> > and in any case, why would this apply to one subroutine and not to a
> second
> > one, more or less the same size?
>
> Procedures which are called from only one location are always(?)
> inlined, regardless of size.
>
>
> --
> Janne Blomqvist
>
Reply | Threaded
Open this post in threaded view
|

Re: Inner functions & -pg

Thomas Koenig-6
In reply to this post by Salvatore Filippone-3
Am 12.10.19 um 11:21 schrieb Salvatore Filippone:
> The contained subroutines are large, I  doubt inlining went into effect;
> and in any case, why would this apply to one subroutine and not to a second
> one, more or less the same size?

The decisions of the middle end are sometimes mysterious :-)

What you can do is to compile your sources with -fdump-tree-optimized
and the optimization level you use, and then look for the occurrence
of the function.

Another think that you may see is that the function is cloned for
certain arguments.  So, if you use

    call foo(a,5)

a lot, it can happen that you will see a function named foo.0.constprop
(or similar) in the tree dump.