| Summary: | Fortran INTENT information not used in the middle-end for optimizations | ||
|---|---|---|---|
| Product: | gcc | Reporter: | Steven Bosscher <steven> |
| Component: | middle-end | Assignee: | Not yet assigned to anyone <unassigned> |
| Status: | RESOLVED FIXED | ||
| Severity: | enhancement | CC: | dberlin, dfranke, fxcoudert, gcc-bugs, P.Schaffnit, pinskia, tkoenig |
| Priority: | P2 | Keywords: | alias, missed-optimization |
| Version: | 4.1.0 | ||
| Target Milestone: | --- | ||
| See Also: | https://gcc.gnu.org/bugzilla/show_bug.cgi?id=34721 | ||
| Host: | Target: | ||
| Build: | Known to work: | ||
| Known to fail: | Last reconfirmed: | 2010-07-13 10:37:16 | |
| Bug Depends on: | 38691 | ||
| Bug Blocks: | |||
Confirmed. No it is not. There are a couple of problems here. First I noticed that bar in foo is not marked as pure even though the IPA mechanism marked it as such, so that looks like a fortran front-end bug in that it has two different DECLs for the same function. The second issue after that is filed as PR 24287 which talks about pure functions causing local variables to be call clobbered even though they don't escape. This issue is related to PR 23134 also. Here is a testcase which we would not get unless we take intent(in) into account: integer function foo(b,c) integer, intent(in) :: b, c integer :: d, e d = b; e = c; call bar(b,c) foo = d-b + e-c; end function foo should always be zero as bar should not be able to touch b or c. A C equivalent test case "works". Once the infamous multiple-decls-per-function issue in gfortran is fixed, this bug probably will disappear. *** Bug 36076 has been marked as a duplicate of this bug. *** (In reply to comment #4) > Here is a testcase which we would not get unless we take intent(in) into > account: [...] > foo should always be zero as bar should not be able to touch b or c. Is this really related to the INTENT? For the equivalent C/C++ cases, I tried prototypes with int, int*, const int*, int& and const int& respectively -- only if the arguments are passed by value, the return value of foo is optimized to zero (as shown by "-O3 -fdump-tree-optimized"). There is no way to tell the middle-end about anonymous readonly memory. (In reply to comment #8) > There is no way to tell the middle-end about anonymous readonly memory. So, we could either - teach that to the middle-end (I couldn't, though :-) - make a duplicate variable for intent(in) variables, to transfer the test case from comment #4 into integer function foo(b,c) integer, intent(in) :: b, c integer :: b_shadow, c_shadow; integer :: d, e b_shadow = b; c_shadow = c; d = b_shadow; e = c_shadow; call bar(b,c) foo = d-b_shadow + e-c_shadow; end function foo Maybe realted: PR29697?! The original testcase in #0 appears to be fixed if compiled with -fwhole-file. Andrew's comment #4 appears to be still an issue?! (In reply to comment #11) > The original testcase in #0 appears to be fixed if compiled with -fwhole-file. > Andrew's comment #4 appears to be still an issue?! Here's a full testcase showing the remaining issue: integer function foo() interface integer function bar(b) integer, intent(in) :: b end function end interface integer :: b, d, k b = 12 d = b k = bar(b) foo = d - b end function In this code, the return value of function foo should not be computed, because it's guaranteed to be 0. The missed optimization is still present. This is something that the middle-end should be taught to honour, so I'm switching the component to middle-end. Still present. (In reply to comment #13) > Still present. Well, INTENT(IN), nonclobber, and something more is now supported by the middle end through the "fn spec" attribute (space to make sure this attribute stays internal for now). INTENT(OUT) could be added, but has not so far. Cf. PR fortran/43665. See also: - "Call argument flags." in tree.h - "gimple_call_arg_flags" in gimple.c - Initial patch: http://gcc.gnu.org/ml/fortran/2010-05/msg00032.html - Committal: http://gcc.gnu.org/ml/fortran/2010-05/msg00092.html This PR seems to have been fixed by revision 165559 or earlier. Closing as FIXED. Please reopen if I am wrong. |
In the function bar, the INTENT(IN) markers mean that p and q may not be modified by bar. This means that the constants 3 and 12 can be progagated in the function foo. My guess is that there should be some way for alias analysis to be taught about this, so I've added the experts to the CC: list. integer function foo(a,b,c) integer, intent(out) :: a integer, intent(in) :: b, c integer p, q p = 3 q = 12 a = bar(b,c,p,q) foo = p*q end function integer function bar(b,c,p,q) integer, intent(in) :: b, c, p, q bar = p*b + q*c end function