http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48636
Janne Blomqvist <jb at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jb at gcc dot gnu.org
--- Comment #6 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-04-20 11:21:15
UTC ---
Note that some of these issues might change with the new array descriptor that
we must introduce at some point (the hope is that it'll get in for 4.7, but it
remains to be seen if there is enough time). See
http://gcc.gnu.org/wiki/ArrayDescriptorUpdate
For instance (comments inline):
(In reply to comment #4)
> (In reply to comment #3)
>
> > The second item is interesting - it would be cool if backend was able to
> > work
> > out that the code is supposed to simplify after inlining. Either by itself
> > or
> > by frontend hint.
> > Can you provide me very simple testcase for that I can look into how it
> > looks
> > like in backend? Perhaps some kind of frontend hinting would work well
> > here.
>
> 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))
Not strictly related to inlining, but in the new descriptor we'll have a field
specifying whether the array is simply contiguous, so it might make sense to
generate two loops for each loop over the array in the source, one for the
contiguous case where it can be vectorized etc. and another loop for the
general case. This might reduce the profitability of inlining.
> - Expensive setting up of, and reading from the array descriptor
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
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.
