[Bug lto/60061] New: Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90

[Bug lto/60061] New: Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90

[dominiq at lps dot ens.fr]

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

            Bug ID: 60061
           Summary: Different dump-ipa-cp-details without/with -flto for
                    gfortran.dg/pr53787.f90
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dominiq at lps dot ens.fr
                CC: hubicka at gcc dot gnu.org, rguenth at gcc dot gnu.org

The outputs pr53787_lto.f90.046i.cp of 

gfortran /opt/gcc/work/gcc/testsuite/gfortran.dg/pr53787.f90 -S -O3
-fdump-ipa-cp-details -fno-inline -fwhole-program

and

gfortran /opt/gcc/work/gcc/testsuite/gfortran.dg/pr53787.f90 -S -O3
-fdump-ipa-cp-details -fno-inline -fwhole-program -flto

differ. In particular the regexps in the test are no longer present with -flto:

...
-Evaluating opportunities for init/0.
- - Creating a specialized node of init/0 for all known contexts.
-      cannot change function signature
-     the new node is init_.constprop.0/8.
-     Aggregate replacements: 1[0]=10
-
-Evaluating opportunities for init/0.
-  Marking node as dead: init/0.
+Evaluating opportunities for init_/0.
...
-Modification phase of node init_.constprop.0/8
-     Aggregate replacements: 1[0]=10
-Modifying stmt:
-  _2 = *n_1(D);
-into:
-  _2 = 10;
+  <bb 3>:
...

Is this expected? If yes, are there better regexps to scan?

[Bug lto/60061] Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-02-05
                 CC|                            |jamborm at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
The dumps seem to be different for the Jump functions already.  It seems that
passing -flto makes the machinery behave differently for some reason
(note this is compile-stage only so make sure to also pass -ffat-lto-objects).

Martin?  Honza?

Maybe this is because of

ipa_compute_jump_functions (struct cgraph_node *node,
                            struct param_analysis_info *parms_ainfo)
{
  struct cgraph_edge *cs;

  for (cs = node->callees; cs; cs = cs->next_callee)
    {
      struct cgraph_node *callee = cgraph_function_or_thunk_node (cs->callee,
                                                                  NULL);
      /* We do not need to bother analyzing calls to unknown
         functions unless they may become known during lto/whopr.  */
      if (!callee->definition && !flag_lto)
        continue;

?  Or other flag_lto tests?  Or maybe this is just because -fwhole-program
is interpreted differently when used with/without -flto?  Indeed the
actual transforms of -flto -fwhole-program match those of -fno-lto
-fno-whole-program.

[Bug lto/60061] Different dump-ipa-cp-details without/with -flto for gfortran.dg/pr53787.f90

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor <jamborm at gcc dot gnu.org> ---
I see init cloned in both -fwhole-program ipa-cp dumps and in WPA
-flto dumps (i.e. when omitting the -S option).

Apparently, when creating fat LTO object file -fwhole-program does not
apply during the compilation phase (which is a bit confusing but I
tend to believe it is a good thing), we thus do not know that we would
clone init for all contexts and it is considered too cold for creating
an extra clone (which is also a good decision).

But non-lto -fwhole-program should be compared to -flto WPA stage, not
fat object optimization phase (assuming it is OK that -fwhole-program
in LTO only applies during the WPA phase).

Yes, jump functions are different exactly because of the condition
quoted above, there is little use analyzing them when they lead to
something unknown that is going to stay unknown.