[Bug middle-end/40194] fortran rules for optimizing

[Bug middle-end/40194] fortran rules for optimizing

[Joost.VandeVondele at mat dot ethz.ch]

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

--- Comment #10 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2012-06-29 14:14:16 UTC ---
this testcase now looks optimized (at least the optimized dump contains return
1; as expected). I guess this can be closed ?

[Bug middle-end/40194] fortran rules for optimizing

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch
         Resolution|                            |FIXED

--- Comment #11 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2013-03-29 09:07:25 UTC ---
Fixed.

[Bug middle-end/40194] New: fortran rules for optimizing

[jv244 at cam dot ac dot uk]

The return value of this function is known at compile time, but from looking at
dump-tree-optimized this seems not to be optimized as such.

INTEGER FUNCTION F1()
  INTEGER :: I1
  INTEGER, TARGET :: I2
  INTEGER, POINTER :: IP

  INTERFACE
    SUBROUTINE S(I1,I2)
      INTEGER,INTENT(IN) :: I1
      INTEGER, POINTER :: IP
    END SUBROUTINE S
  END INTERFACE

  I1=1
  I2=1
  IP=>I2
  CALL S(I1,IP)
  IP=2

  F1=I1
END FUNCTION F1

F1=1 can be infered from the fact that it is an intent(in) argument of S (so
the value cant be changed within S), and the fact that I1 does not have the
target attributed, so can not be 'aliased' with the pointer IP.


-- 
           Summary: fortran rules for optimizing
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jv244 at cam dot ac dot uk


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

------- Comment #1 from jv244 at cam dot ac dot uk  2009-05-19 10:01 -------
OK, updated testcase, while the argument still holds for the previous code,
this was the intended code, and the generated code is even worse:

INTEGER FUNCTION F1()
  INTEGER :: I1
  INTEGER, TARGET :: I2
  INTEGER, POINTER :: IP

  INTERFACE
    SUBROUTINE S(I1,IP)
      INTEGER,INTENT(IN) :: I1
      INTEGER, POINTER :: IP
    END SUBROUTINE S
  END INTERFACE

  I1=1
  I2=1
  IP=>I2
  CALL S(I1,IP)
  IP=2

  F1=I1
END FUNCTION F1


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

------- Comment #2 from jv244 at cam dot ac dot uk  2009-05-19 10:14 -------
the context of the report is 

http://gcc.gnu.org/ml/gcc/2009-05/msg00465.html

in particular, fortran variables are often not 'addressable' in the sense that
seems to be important of the gcc optimizers


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

------- Comment #3 from rguenth at gcc dot gnu dot org  2009-05-19 10:20 -------
Does

    SUBROUTINE S(I1,IP)
      INTEGER,INTENT(IN) :: I1
      INTEGER, POINTER :: IP
    END SUBROUTINE S

allow that S stores the pointer to I1 to global memory?

I think that the easiest way to improve Fortran code generation is to _not_
pass INTENT(IN) arguments by reference but by value (at least for scalar
types).  Maybe the FE can use DECL_BY_REFERENCE and the middle-end that
to derive non-clobber/escape status.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

------- Comment #4 from rguenth at gcc dot gnu dot org  2009-05-19 10:39 -------
Hmm, DECL_BY_REFERENCE is set too often.  Maybe in addition set/check
TREE_READONLY.


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

------- Comment #5 from jv244 at cam dot ac dot uk  2009-05-19 11:54 -------
(In reply to comment #3)
> Does
> 
>     SUBROUTINE S(I1,IP)
>       INTEGER,INTENT(IN) :: I1
>       INTEGER, POINTER :: IP
>     END SUBROUTINE S
> 
> allow that S stores the pointer to I1 to global memory?

this is not a very Fortran-ish way to express this, and I'm not very C-ish, but
the answer is no (I don't think you can obtain the address of I1 in S1 using
standard conforming Fortran, and certainly there is no guarantee at all that
you get the address of I1 in F1). Even if you get the address of I1, no way
you're allowed to change the value of I1, either in S1, or in any subroutine
called subsequently.

The important thing is not so much that (I believe), but the fact that Fortran
guarantees that in the caller where I1 is defined (i.e. F1), nothing else can
alias that variable.

> I think that the easiest way to improve Fortran code generation is to _not_
> pass INTENT(IN) arguments by reference but by value (at least for scalar
> types).

I believe that his is some kind of misunderstanding. It is not because the FE
generates some code that is call by reference that his is actually what the
rules are. AFAICT, it would be equally valid for a Fortran implementation to
copy in and copy out the data (i.e. the address of the variable in the caller
is of no importance in the callee).

I think it would be worthwhile to discuss this once with the group of
gcc-people that know both Fortran and the middle-end really well (I hope this
is a non-zero subset :-)


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2009-05-19 12:04 -------
The intel compiler passes I1 by value:

..___tag_value_f1_.1:                                           #1.18
        subq      $24, %rsp                                     #1.18
..___tag_value_f1_.3:                                           #
        lea       12(%rsp), %rcx                                #15.3
        movq      %rcx, (%rsp)                                  #15.3
        lea       8(%rsp), %rdi                                 #16.8
        movl      $1, %edx                                      #13.3
        xorl      %eax, %eax                                    #16.8
        movl      %edx, 8(%rsp)                                 #13.3
        movl      %edx, 12(%rsp)                                #14.3
        lea       (%rsp), %rsi                                  #16.8
        call      s_                                            #16.8
                                # LOE rbx rbp r12 r13 r14 r15
..B1.2:                         # Preds ..B1.1
        movq      (%rsp), %rdx                                  #17.3
        movl      8(%rsp), %eax                                 #20.1
        movl      $2, (%rdx)                                    #17.3
        addq      $24, %rsp                                     #20.1
..___tag_value_f1_.4:                                           #
        ret                                                     #20.1

even though it's code generation is funny at -O2 ...


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[rguenth at gcc dot gnu dot org]

------- Comment #7 from rguenth at gcc dot gnu dot org  2009-05-19 12:10 -------
Hm, no.  It doesn't pass it by value.


-- 


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

[Bug middle-end/40194] fortran rules for optimizing

[jv244 at cam dot ac dot uk]

------- Comment #8 from jv244 at cam dot ac dot uk  2009-08-13 07:23 -------
Michael,

this is somewhat related to your 'restrict-for-fortran-patch'

http://gcc.gnu.org/ml/gcc-patches/2009-08/msg00610.html

do you think it also fixes the issue here ?


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at suse dot de


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

[Bug middle-end/40194] fortran rules for optimizing

[matz at gcc dot gnu dot org]

------- Comment #9 from matz at gcc dot gnu dot org  2009-08-13 12:16 -------
It is indeed somewhat related, but currently the patchset doesn't help here.
The first issue is, that I create new types with unconflicting alias sets
only for global variables, not local ones (as I1 is in this case).  I believe
I can change this meanwhile (the restriction came from earlier versions of
the patch).  But even if this is fixed we can't figure out the difference
between INTENT(IN) and INTENT(OUT), i.e. even then we still believe that 
I1 can possibly be changed by the call.

We have three ways out of this:
1) make the frontend not pass INTENT(IN) parameters by reference, maybe
   at least for scalars.  That would be the preferred way, but unfortunately
   this probably would break a lot of code assuming such calling convention
   especially when interfacing with C code :-/
2) invent a new attribute that we can attach to the individual arguments
   that would indicate non-clobbering via this reference
3) find a combination of existing things (DECL_BY_REFERENCE/TREE_READONLY/etc)
   that could be used by the middle end to conclude non-clobbering.
   Something like a const reference comes to mind, but unfortunately (the
   middle-end coming mostly from the C/C++ side) we don't conclude many
   interesting things about const refs/pointers.


-- 


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