[Bug target/94841] New: [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto

[Bug target/94841] New: [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto

[crazylht at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841

            Bug ID: 94841
           Summary: [10 Regression]527.cam4_r 7.68% regression on Intel
                    Cascadelaker with -O2, 9.57% regression with -Ofast
                    -march=native -funroll-loops -flto
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
                CC: hjl.tools at gmail dot com, tkoenig at gcc dot gnu.org,
                    wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
            Target: i386, x86-64

Starting with

----
commit 06eca1acafa27e19e82dc73927394a7a4d0bdbc5
Author: Thomas König <tkoenig@gcc.gnu.org>
Date:   Thu Apr 23 20:30:01 2020 +0200

    Fix PR 93956, wrong pointer when returned via function.

    This one took a bit of detective work.  When array pointers point
    to components of derived types, we currently set the span field
    and then create an array temporary when we pass the array
    pointer to a procedure as a non-pointer or non-target argument.
    (This is inefficient, but that's for another release).

    Now, the compiler detected this case when there was a direct assignment
    like p => a%b, but not when p was returned either as a function result
    or via an argument.  This patch fixes that.

    2020-04-23  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/93956
            * expr.c (gfc_check_pointer_assign): Also set subref_array_pointer
            when a function returns a pointer.
            * interface.c (gfc_set_subref_array_pointer_arg): New function.
            (gfc_procedure_use): Call it.

    2020-04-23  Thomas Koenig  <tkoenig@gcc.gnu.org>

            PR fortran/93956
            * gfortran.dg/pointer_assign_13.f90: New test.

------

[Bug fortran/94841] [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |26163
   Last reconfirmed|                            |2020-04-29
           Keywords|                            |missed-optimization
             Status|UNCONFIRMED                 |WAITING
   Target Milestone|---                         |10.0
     Ever confirmed|0                           |1
          Component|target                      |fortran

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Probably the mentioned inefficiency but the fix was a correctness one.

Needs a testcase, fortran folks do not have access to SPEC and the question
is whether the inefficiency can be fixed for the problematical case(s).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug fortran/94841] [10 Regression]527.cam4_r 7.68% regression on Intel Cascadelaker with -O2, 9.57% regression with -Ofast -march=native -funroll-loops -flto

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94841

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=94788,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93956,
                   |                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=93114
             Status|WAITING                     |RESOLVED

--- Comment #2 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> Probably the mentioned inefficiency but the fix was a correctness one.

I had to revert the patch because fixing one correctness issue introduced
another one (PR 94788).

> Needs a testcase, fortran folks do not have access to SPEC and the question
> is whether the inefficiency can be fixed for the problematical case(s).

In this particular case, the cause of the inefficiency is clear - creating
a temporary because it is not kown if a pointer returned from a
procedure has a span or not. And if we don't know, we need to do something
about that, such as creating a temporary.

We need to revisit this whole thing for gcc 11, also for PR 93114.

I have some ideas already.  Marking this as fixed in the meantime.