Bug 31094 - Support annotating function parameters as read-only and/or non-escaping
Summary: Support annotating function parameters as read-only and/or non-escaping
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Michael Matz
URL:
Keywords: missed-optimization
Depends on:
Blocks: 31279 31593 31893
  Show dependency treegraph
 
Reported: 2007-03-09 07:17 UTC by Tobias Burnus
Modified: 2018-02-19 04:53 UTC (History)
8 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-10-08 11:23:04


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2007-03-09 07:17:17 UTC
http://gcc.gnu.org/ml/fortran/2007-02/msg00167.html
> > > From what I've seen, one of the main problems with Fortran and
> > > aliasing is the pass-by-reference rule in Fortran.  This often tricks 
> > > alias analysis into overstating the amount of call-clobbered variables.
> > Can we do something in the frontend to overcome the pass-by-reference
> > rule? Can some of the analysis be done where we have the information
> > and the variables be marked up ins some way?
> We need middle-end support to annotate function parameters as read-only
> and/or non-escaping.

Fortran allows to specify that certain arguments of procedures (functions and subroutines) have "intent(in)", i.e. are not modified by the procedure, or to be "intent(out)", i.e. their value on entry might be undefined.

Additionally, there exist PURE functions, which may not modify any of the passed arguments nor global variables. This is actually also true for many functions provided by the Fortran library, e.g. matrix products ("matmul()") or dot_product()s; while for simple cases they are inlined, for more complicated ones (e.g. several dimensions with strides) they are not but a call to the Fortran library is generated.

Even if a temporary variable is created, one can do optimizations:
{
  real D.14354;
  D.14354 = foo; // Not needed for intent(out)
  bar(&D.14354);
  foo = D.14354; // Not needed for intent(in)
}

(In Fortran code: "call bar(foo)" where bar is defined, e.g., as:
"subroutine bar(a); real, intent(in) :: a")
Comment 1 Richard Biener 2007-03-09 10:33:54 UTC
Confirmed.
Comment 2 Manuel López-Ibáñez 2008-01-10 15:38:29 UTC
Isn't this similar to 

include <stdio.h>
main()
{
 char foo[10];
 printf("%s", foo);
}

and other functions that we know for sure don't modify their arguments. It seems a missed optimisation not only for Fortran.
Comment 3 Manuel López-Ibáñez 2008-01-10 15:40:00 UTC
Actually, that is for Wuninitialized. For a missed optimisation:

#include <stdio.h>
char foo()
{
  char str[] = "Hola";

  char c;

  printf("%s", str);
  c = str[0];
  return c;
}
Comment 4 Michael Matz 2009-10-08 11:23:04 UTC
We're (slowly) working on this.
Comment 5 Michael Matz 2009-10-08 11:26:14 UTC
See also my mail http://gcc.gnu.org/ml/fortran/2009-08/msg00200.html
about this issue.
Comment 6 Sylwester Arabas 2012-04-24 08:50:52 UTC
Perhaps that's somehow related to the issue described in this message:
http://gcc.gnu.org/ml/fortran/2012-04/msg00122.html
Sylwester
Comment 7 Dominique d'Humieres 2013-06-25 09:08:05 UTC
Is this PR fixed by revision 165559 or not?
Comment 8 Richard Biener 2013-08-28 08:25:37 UTC
Not sure - the middle-end now has the 'fn spec' attribute, so middle-end support
is ready.  The revision in question only marks IO library calls properly,
not as requested user functions with INTENT(IN)/INTENT(OUT) (?)

So, closing the middle-end part as fixed (this was a middle-end bug).

Eventually a Fortran bug still needs to be opened.