RFA: matmul/transpose optimisation

[Richard Sandiford]

Steve Kargl <sgk@troutmask.apl.washington.edu> writes:
> On Tue, Dec 06, 2005 at 06:18:37PM +0000, Richard Sandiford wrote:
>> At the moment, we don't have an easy way of determining the intent
>> of an intrinsic function argument.  The patch therefore treats all
>> such arguments as having unknown intent.  Thus:
>> 
>>     b = matmul (transpose (a), a)
>> 
>> will not be optimised, because we assume that the second argument
>> to matmul() might not be intent(in).  This can be cleaned up later
>> if we ever have a direct representation of an intrinic function's
>> interface.
>> 
>
> I must be misinterpreting what you've written here.  We
> know the argument to transpose is intent(in) and we know
> the arguments to matmul are intent(in).  We additionally
> know that neither matmul nor transpose can have side effects.
> This is guaranteed via 13.1 and 13.3

"We" here means Fortran programmers, right?  If so, then of course,
but that wasn't my point.  My point was that the _compiler_ does not
"have an easy way of determining the intent of an intrinsic function
argument".  It isn't part of the information given when registering
intrinsics.  And:

   13.3 ... "The nonpointer dummy arguments of the generic intrinsic
             procedures in 13.14 have INTENT(IN) if the intent
             is not explicitly stated."

shows that the standard _does_ define intrinsics whose arguments
have other intents.  Gfortran also supports non-standard intrinsics,
and will probably support more in future.  There's no guarantee that
such intrinsics will all have arguments of intent(in).

Also bear in mind that this is supposed to be a bit of infrastructure
that would be extended to other optimisations.  You could argue that the
standard doesn't define any intrinsics that take rank-2 arrays and
non-intent(in) arguments (I remember checking this before submitting
the original patch, and convincing myself that it's true).  But other
non-copying intrinsics may not be so lucky.

I really think that determining the correct intent of intrinsic
arguments is something that should be handled separately.  It's not
needed for most instances of the optimisation that this patch is trying
to perform.  Better to stick to single-feature patches where possible.

Once we have a bit of infrastructure for recording which intrinsics
arguments have which intents, we can update dependence.c accordingly.

Richard