[Bug fortran/48636] Enable more inlining with -O2 and higher

["jb at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636

--- Comment #8 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-04-20 13:09:51 UTC ---
(In reply to comment #7)
> (In reply to comment #6)
> > > Here is some sample code (extreme, I admit) which profits a lot from
> > > inlining:
> > > 
> > > - Strides are known to be one when inlining (a common case, but you can
> > >   never be sure if the user doesn't call a(1:5:2))
> 
> First, you do not have any issue with strides if the dummy argument is either
> allocatable, has the contiguous attribute, or is an explicit or assumed-sized
> array.
> 
> For inlining, I see only one place where information loss happens: If a
> simply-contiguous array is passed as actual argument to a assumed-shape dummy.
> Then the Fortran front-end knows that the stride of the actual argument is 1,
> but the callee needs to assume an arbitrary stride. The middle-end will
> continue to do so as the "simply contiguous" information is lost - even though
> it would be profitable for inlining.

Passing simply contiguous arrays to assumed-shape dummies is a fairly common
case in "modern Fortran", so it would be nice if we could generate fast code
for this.

> > Not strictly related to inlining, but in the new descriptor we'll have a field
> > specifying whether the array is simply contiguous
> 
> I am not sure we will indeed have one; initially I thought one should, but I am
> no longer convinced that it is the right approach. My impression is now that
> setting and updating the flag all the time is more expensive then doing once a
> is_contiguous() check.

Hmm, maybe. Shouldn't it be necessary to update the contiguous flag only when
passing slices to procedures with explicit interfaces? But OTOH, calculating
whether an array is simply contiguous at procedure entry is just a few
arithmetic operations anyway. But, in any case I don't have any profiling data
to argue which approach would be better. 

> The TR descriptor also does not such an flag - thus one
> needs to handle such arrays - if they come from C - with extra care. (Unless
> one requires the C side to call a function, which could set this flag. I think
> one does not need to do so.)

I suppose one cannot require the C side to set such a flag, as the TR doesn't
require its presence? Thus we'd need to calculate whether the array is simply
contiguous anyway if it's possible the array comes from C. Do such procedures
have to be marked with BIND(C) in some way or how does this work? 

In any case, maybe this is what tips it in favor of always calculating the
contiguousness instead of having a flag in the descriptor - it would be one
single way of handling it, reducing the possibility of bugs. Also, if the
contigousness isn't used for anything in the procedure, the dead code
elimination should delete it anyway.

> > As we're planning to use the TR 29113 descriptor as the native one, this has
> > some implications for the procedure call interface as well. See
> > http://gcc.gnu.org/ml/fortran/2011-03/msg00215.html
> 
> Regarding:
> "For a descriptor of an assumed-shape array, the value of the
> lower-bound member of each element of the dim member of the descriptor
> shall be zero."
> 
> That's actually also not that different from the current situation: In Fortran,
> the lower bound of assumed-shape arrays is also always the same: It is 1.

Yes. But what is different from the current situation is that the above is what
the standard requires semantically, and the implementation is free to implement
it as it sees fit. In the TR, OTOH, we have the explicit requirement that on
procedure entry the lower bounds in the descriptor should be 0. This of course
applies only to inter-operable procedures, for "pure Fortran" we're still free
to do as we please. But again, it might make sense to do it the same way in
both cases in order to reduce the implementation and maintenance burden.

> For explicit-shape/assumed-size arrays one does not have a descriptor and for
> deferred-shape arrays (allocatables, pointers) the TR keeps the lbound - which
> is the same as currently in Fortran.

Yes.

> > This will reduce the procedure call overhead substantially, at the cost
> > of some extra work in the caller in the case of non-default lower bounds.
> 
> Which is actually nothing new ... That's the reason that one often creates a
> new descriptor for procedure calls.

But do we actually do this? I did some tests a while ago, and IIRC for assumed
shape dummy arguments the procedure always calculates new bounds such that they
start from 1. That is, the procedure assumes that the actual argument
descriptor may have lower bounds != 1. 

So my argument is basically that with the new descriptor it might make sense to
switch the responsibility around such that it's the caller who makes sure that
all lower bounds are 0 (as we must have the capability to do this anyway in
order to call inter-operable procedures, no?) instead of the callee.