[Bug lto/51663] New: LTO does not reclaim comdat-local statics

[Bug lto/51663] New: LTO does not reclaim comdat-local statics

[rguenth at gcc dot gnu.org]

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

             Bug #: 51663
           Summary: LTO does not reclaim comdat-local statics
    Classification: Unclassified
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: rguenth@gcc.gnu.org
                CC: hubicka@gcc.gnu.org


struct T;
struct C
{
    typedef ::T T;
    virtual void E();
    static T *m ()
      {
        static T *d;
        return d;
      }
};
int
fn ()
{
  C::m ();
}
int main() {}

The C++ frontend with -fwhole-program reclaims C::m::d, but LTO using
the linker plugin does not.  See PR51650 comment #15 and #16 for some
analysis.

[Bug lto/51663] LTO does not reclaim comdat-local statics

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-04 12:49:47 UTC ---
It's interesting that with a simplified testcase

struct T;
static T *m ()
{   
  static T *d; 
  return d;
}   
int
fn ()
{
  m ();
}
int main() {}

The C++ frontend with -fwhole-program no longer removes m::d, so this is
maybe a general issue, not LTO specific.

[Bug lto/51663] LTO does not reclaim comdat-local statics

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-01-04
     Ever Confirmed|0                           |1

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-01-04 12:54:33 UTC ---
Smaller testcase:

int m ()
{   
  static int d;
  return d;
}   
int main() {}

Does not eliminate m::d with -O0 -fwhole-program (but does, with -O1).
It does eliminate m with -O0 -fwhole-program.  Similar with LTO and
the original testcase - m::d is only eliminated with optimization.

Odd inconsistency (remember, with -O0 -fwhole-program on the original
testcase m::d is eliminated).

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |hubicka at gcc dot gnu.org
                   |gnu.org                     |

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-20 16:49:44 UTC ---
OK, the funny inconsistency comes from the fact that we always eliminate COMDAT
variables, but we keep around static variables with -fno-toplevel-reorder.
-O0 imply -fno-toplevel-reorder and -fwhole-program brings COMDAT variables
local, just like in this case.

This all envolved for historical reasons.  I wonder how we really want to
behave here...

I am looking into the LTO case. With new plugin API it should just work.
Honza

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-24 20:59:38 UTC ---
Works for me:
jh@evans:/abuild/jh/trunk-3/build-inst7> /abuild/jh/trunk-install/bin/g++  -O2
t.C -flto -c
jh@evans:/abuild/jh/trunk-3/build-inst7> /abuild/jh/trunk-install/bin/g++  -O2
t.o -flto --save-temps
[Leaving LTRANS /tmp/ccy4OrZL.args]
[Leaving LTRANS /tmp/ccFrEQBZ.ltrans.out]
[Leaving LTRANS /tmp/ccMy8uNk.args]
[Leaving LTRANS /tmp/ccFrEQBZ.ltrans0.o]
jh@evans:/abuild/jh/trunk-3/build-inst7> more *ltrans*s
        .file   "ccFrEQBZ.ltrans0.o"
        .section        .text.startup,"ax",@progbits
        .p2align 4,,15
        .globl  main
        .type   main, @function
main:
.LFB0:
        .cfi_startproc
        xorl    %eax, %eax
        ret
        .cfi_endproc
.LFE0:
        .size   main, .-main
        .ident  "GCC: (GNU) 4.8.0 20120324 (experimental)"
        .section        .note.GNU-stack,"",@progbits

So this is all about -O0?
At -O0 I get:
       .local  _ZZN1C1mEvE1d.local.1.2356
        .comm   _ZZN1C1mEvE1d.local.1.2356,8,8

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-24 21:07:34 UTC ---

The resolution info seems to be right, unlike the aforementioned comment.
d: availability:overwritable (asm: _ZZN1C1mEvE1d) needed analyzed finalized
externally_visible prevailing_def_ironly

The reason why it stays in the code is again the logic of promoting it to
static var and consequentely not removing the variable at -O0.  I wonder what
policy we want here.

I think some folks still rely on static vars not being removed at -O0. We
probably could remove local statics of functions that has been removed, but
that is an odd rule.  

Perhaps we may want to set flag forcing static vars in the code at -O0 instead
of testing the flag late.  (effectively making -O0 to drop implicit used flag
on everything). This way the behaviour will be consistet over -fwhole-program
and not.

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-24 21:39:16 UTC ---
OK,
this should regularize the situation somewhat. We handle the
-O0/-fno-toplevel-reorder semantics early at finalization time and thus we
don't care about effect of -fwhole-program and friends.

        * varpool.c (varpool_finalize_decl): Handle toplevel_reorder here.
        (decide_is_variable_needed): Do not handle toplevel reorder here.
        * cgraph.h (varpool_can_remove_if_no_refs): Likewise.
Index: varpool.c
===================================================================
--- varpool.c   (revision 183666)
+++ varpool.c   (working copy)
@@ -334,10 +334,6 @@ decide_is_variable_needed (struct varpoo
       && !DECL_EXTERNAL (decl))
     return true;

-  /* When not reordering top level variables, we have to assume that
-     we are going to keep everything.  */
-  if (!flag_toplevel_reorder)
-    return true;
   return false;
 }

@@ -405,7 +401,11 @@ varpool_finalize_decl (tree decl)
   if (node->needed)
     varpool_enqueue_needed_node (node);
   node->finalized = true;
-  if (TREE_THIS_VOLATILE (decl) || DECL_PRESERVE_P (decl))
+  if (TREE_THIS_VOLATILE (decl) || DECL_PRESERVE_P (decl)
+      /* Traditionally we do not eliminate static variables when not
+        optimizing and when not doing toplevel reoder.  */
+      || (!flag_toplevel_reorder && !DECL_COMDAT (node->decl)
+         && !DECL_ARTIFICIAL (node->decl)))
     node->force_output = true;

   if (decide_is_variable_needed (node, decl))
Index: cgraph.h
===================================================================
--- cgraph.h    (revision 183666)
+++ cgraph.h    (working copy)
@@ -947,8 +947,6 @@ static inline bool
 varpool_can_remove_if_no_refs (struct varpool_node *node)
 {
   return (!node->force_output && !node->used_from_other_partition
-         && (flag_toplevel_reorder || DECL_COMDAT (node->decl)
-             || DECL_ARTIFICIAL (node->decl))
          && (DECL_COMDAT (node->decl) || !node->externally_visible));
 }

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-25 13:28:36 UTC ---
Author: hubicka
Date: Sun Mar 25 13:28:32 2012
New Revision: 185777

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185777
Log:
    PR lto/51663
    * varpool.c (varpool_finalize_decl): Handle toplevel_reorder here.
    (decide_is_variable_needed): Do not handle toplevel reorder here.
    * cgraph.h (varpool_can_remove_if_no_refs): Likewise.
    * ipa.c (cgraph_remove_unreachable_nodes): Remove unreachable vars
    even at -O0.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cgraph.h
    trunk/gcc/ipa.c
    trunk/gcc/varpool.c

[Bug lto/51663] LTO does not reclaim comdat-local statics

[hubicka at gcc dot gnu.org]

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-03-25 13:50:39 UTC ---
The inconsistency should be solved. The question however is what kind of
behaviour we want at -O0 from LTO.

It seems to me that at -O0 the LTO/non-LTO output should be as close as
possible and thus LTO should not privatize symbols and break more silly
debuggers/tools (this is especially important for SLIM mode).

We still do renaming of statics and other nasty things, but we should not do
more than neccesary.

On the the other hand, I think -fwhole-program should still do privatization.
This patch implements it.  In addition to this it drops more unobvious
transformation from -fwhole-program where we bring local COMDAT virtual tables
and functions w/o address taken since we know duplicating them does not hurt.

Does this look sane?

Honza

Index: ipa.c
===================================================================
--- ipa.c       (revision 185777)
+++ ipa.c       (working copy)
@@ -616,7 +616,8 @@ cgraph_externally_visible_p (struct cgra
   if (TARGET_DLLIMPORT_DECL_ATTRIBUTES
       && lookup_attribute ("dllexport", DECL_ATTRIBUTES (node->decl)))
     return true;
-  if (node->resolution == LDPR_PREVAILING_DEF_IRONLY)
+  if (node->resolution == LDPR_PREVAILING_DEF_IRONLY
+      && optimize)
     return false;
   /* When doing LTO or whole program, we can bring COMDAT functoins static.
      This improves code quality and we know we will duplicate them at most
twice
@@ -624,11 +625,13 @@ cgraph_externally_visible_p (struct cgra
       implementing same COMDAT)  */
   if ((in_lto_p || whole_program)
       && DECL_COMDAT (node->decl)
+      && optimize
       && cgraph_comdat_can_be_unshared_p (node))
     return false;

   /* When doing link time optimizations, hidden symbols become local.  */
   if (in_lto_p
+      && optimize
       && (DECL_VISIBILITY (node->decl) == VISIBILITY_HIDDEN
          || DECL_VISIBILITY (node->decl) == VISIBILITY_INTERNAL)
       /* Be sure that node is defined in IR file, not in other object
@@ -681,7 +684,8 @@ varpool_externally_visible_p (struct var
      This is needed for i.e. references from asm statements.   */
   if (varpool_used_from_object_file_p (vnode))
     return true;
-  if (vnode->resolution == LDPR_PREVAILING_DEF_IRONLY)
+  if (vnode->resolution == LDPR_PREVAILING_DEF_IRONLY
+      && optimize)
     return false;

   /* As a special case, the COMDAT virutal tables can be unshared.
@@ -690,6 +694,7 @@ varpool_externally_visible_p (struct var
      is faster for dynamic linking.  Also this match logic hidding vtables
      from LTO symbol tables.  */
   if ((in_lto_p || flag_whole_program)
+      && optimize
       && !vnode->force_output
       && DECL_COMDAT (vnode->decl) && DECL_VIRTUAL_P (vnode->decl))
     return false;

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-03-26 07:05:58 UTC ---
(In reply to comment #8)
> The inconsistency should be solved. The question however is what kind of
> behaviour we want at -O0 from LTO.
> 
> It seems to me that at -O0 the LTO/non-LTO output should be as close as
> possible and thus LTO should not privatize symbols and break more silly
> debuggers/tools (this is especially important for SLIM mode).
> 
> We still do renaming of statics and other nasty things, but we should not do
> more than neccesary.
> 
> On the the other hand, I think -fwhole-program should still do privatization.
> This patch implements it.  In addition to this it drops more unobvious
> transformation from -fwhole-program where we bring local COMDAT virtual tables
> and functions w/o address taken since we know duplicating them does not hurt.
> 
> Does this look sane?

Yes.  I think for -O0 -flto we should default to 1:1 partitioning and
_not_ do the renaming of local symbols though ... of course -O0 -flto
does not make too much sense?

> Honza
> 
> Index: ipa.c
> ===================================================================
> --- ipa.c       (revision 185777)
> +++ ipa.c       (working copy)
> @@ -616,7 +616,8 @@ cgraph_externally_visible_p (struct cgra
>    if (TARGET_DLLIMPORT_DECL_ATTRIBUTES
>        && lookup_attribute ("dllexport", DECL_ATTRIBUTES (node->decl)))
>      return true;
> -  if (node->resolution == LDPR_PREVAILING_DEF_IRONLY)
> +  if (node->resolution == LDPR_PREVAILING_DEF_IRONLY
> +      && optimize)
>      return false;
>    /* When doing LTO or whole program, we can bring COMDAT functoins static.
>       This improves code quality and we know we will duplicate them at most
> twice
> @@ -624,11 +625,13 @@ cgraph_externally_visible_p (struct cgra
>        implementing same COMDAT)  */
>    if ((in_lto_p || whole_program)
>        && DECL_COMDAT (node->decl)
> +      && optimize
>        && cgraph_comdat_can_be_unshared_p (node))
>      return false;
> 
>    /* When doing link time optimizations, hidden symbols become local.  */
>    if (in_lto_p
> +      && optimize
>        && (DECL_VISIBILITY (node->decl) == VISIBILITY_HIDDEN
>           || DECL_VISIBILITY (node->decl) == VISIBILITY_INTERNAL)
>        /* Be sure that node is defined in IR file, not in other object
> @@ -681,7 +684,8 @@ varpool_externally_visible_p (struct var
>       This is needed for i.e. references from asm statements.   */
>    if (varpool_used_from_object_file_p (vnode))
>      return true;
> -  if (vnode->resolution == LDPR_PREVAILING_DEF_IRONLY)
> +  if (vnode->resolution == LDPR_PREVAILING_DEF_IRONLY
> +      && optimize)
>      return false;
> 
>    /* As a special case, the COMDAT virutal tables can be unshared.
> @@ -690,6 +694,7 @@ varpool_externally_visible_p (struct var
>       is faster for dynamic linking.  Also this match logic hidding vtables
>       from LTO symbol tables.  */
>    if ((in_lto_p || flag_whole_program)
> +      && optimize
>        && !vnode->force_output
>        && DECL_COMDAT (vnode->decl) && DECL_VIRTUAL_P (vnode->decl))
>      return false;

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[hubicka at ucw dot cz]

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

--- Comment #10 from Jan Hubicka <hubicka at ucw dot cz> 2012-03-26 10:44:57 UTC ---
> Yes.  I think for -O0 -flto we should default to 1:1 partitioning and
> _not_ do the renaming of local symbols though ... of course -O0 -flto
> does not make too much sense?

In longer run, I think it would make sense for slim lto, so one don't need to
ship two versions of a same slim-LTO library (one for optimized builds and one
for unoptimized)
Still the LTO code there will be early optimized...

1:1 partitioning has quite serve performance implications that defeat purpose
of -O0, too.

Honza

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[vries at gcc dot gnu.org]

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

Tom de Vries <vries at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vries at gcc dot gnu.org

--- Comment #11 from Tom de Vries <vries at gcc dot gnu.org> ---
Cross-referencing PR gdb/25684 - "gdb testing with gcc -flto" (
https://sourceware.org/bugzilla/show_bug.cgi?id=25684 ).

Ideally there would be a way to enable the lto infrastructure without actually
optimizing, such that when running the gdb testsuite with and without flto and
comparing results, any regression would indicate something that needs fixing.

In the current situation, each individual regression needs investigation
whether something needs fixing or whether the failure is just an optimization
artifact. And due to the fact there are optimizations, there are thousands of
such regressions.

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[rguenth at gcc dot gnu.org]

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

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #11)
> Cross-referencing PR gdb/25684 - "gdb testing with gcc -flto" (
> https://sourceware.org/bugzilla/show_bug.cgi?id=25684 ).
> 
> Ideally there would be a way to enable the lto infrastructure without
> actually optimizing, such that when running the gdb testsuite with and
> without flto and comparing results, any regression would indicate something
> that needs fixing.
> 
> In the current situation, each individual regression needs investigation
> whether something needs fixing or whether the failure is just an
> optimization artifact. And due to the fact there are optimizations, there
> are thousands of such regressions.

I suppose we're talking about -O0 -flto here.  What kind of transforms
are undesirable?  I think at -O0 you'll get

 - more aggressive unused variable/function removal
 - promotion of variables from global to local

some of the transforms are unavoidable due to partitioning(?) but we could
default to 1:1 partitioning at -O0 ...

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[vries at gcc dot gnu.org]

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

--- Comment #13 from Tom de Vries <vries at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> (In reply to Tom de Vries from comment #11)
> > Cross-referencing PR gdb/25684 - "gdb testing with gcc -flto" (
> > https://sourceware.org/bugzilla/show_bug.cgi?id=25684 ).
> > 
> > Ideally there would be a way to enable the lto infrastructure without
> > actually optimizing, such that when running the gdb testsuite with and
> > without flto and comparing results, any regression would indicate something
> > that needs fixing.
> > 
> > In the current situation, each individual regression needs investigation
> > whether something needs fixing or whether the failure is just an
> > optimization artifact. And due to the fact there are optimizations, there
> > are thousands of such regressions.
> 
> I suppose we're talking about -O0 -flto here.

Right, and ideally -flto plain, with -O0 implicit.

>  What kind of transforms
> are undesirable?  I think at -O0 you'll get
> 
>  - more aggressive unused variable/function removal
>  - promotion of variables from global to local
> 

Right, is there a way to switch these off?

> some of the transforms are unavoidable due to partitioning(?) but we could
> default to 1:1 partitioning at -O0 ...

At this point I'm not interested in defaults yet. I can achieve 1:1 partition
by testing target board unix/-flto/-flto-partition=1to1.

For now I'm interested in a combination of flags that exercises the specific
type of debug info generation as is done for lto, without actually doing any
optimizations.

F.i., an open question for me is the following: I'm now using
-flto-partition=none for testing, but maybe 1to1 should yield better results?

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[rguenth at gcc dot gnu.org]

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #13)
> (In reply to Richard Biener from comment #12)
> > (In reply to Tom de Vries from comment #11)
> > > Cross-referencing PR gdb/25684 - "gdb testing with gcc -flto" (
> > > https://sourceware.org/bugzilla/show_bug.cgi?id=25684 ).
> > > 
> > > Ideally there would be a way to enable the lto infrastructure without
> > > actually optimizing, such that when running the gdb testsuite with and
> > > without flto and comparing results, any regression would indicate something
> > > that needs fixing.
> > > 
> > > In the current situation, each individual regression needs investigation
> > > whether something needs fixing or whether the failure is just an
> > > optimization artifact. And due to the fact there are optimizations, there
> > > are thousands of such regressions.
> > 
> > I suppose we're talking about -O0 -flto here.
> 
> Right, and ideally -flto plain, with -O0 implicit.
> 
> >  What kind of transforms
> > are undesirable?  I think at -O0 you'll get
> > 
> >  - more aggressive unused variable/function removal
> >  - promotion of variables from global to local
> > 
> 
> Right, is there a way to switch these off?

Not at the moment I think.  The main unused variable/function removal
is in cgraphunit.c:analyze_functions.  I guess the simplest thing would
be to try

diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c
index a9dd288be57..3aa8137efad 100644
--- a/gcc/cgraphunit.c
+++ b/gcc/cgraphunit.c
@@ -1158,7 +1158,7 @@ analyze_functions (bool first_time)
        {
          /* Convert COMDAT group designators to IDENTIFIER_NODEs.  */
          node->get_comdat_group_id ();
-         if (node->needed_p ())
+         if (!optimize || node->needed_p ())
            {
              enqueue_node (node);
              if (!changed && symtab->dump_file)

but I'm not sure this is enough since we remove not refered to things
at several points during the compilation (including during partitioning
I think).  Another possibility would be to make all nodes force_output
when not optimizing like with

diff --git a/gcc/cgraph.h b/gcc/cgraph.h
index aa4cdc95506..b07bf9745d0 100644
--- a/gcc/cgraph.h
+++ b/gcc/cgraph.h
@@ -115,7 +115,7 @@ public:
       transparent_alias (false), weakref (false), cpp_implicit_alias (false),
       symver (false), analyzed (false), writeonly (false),
       refuse_visibility_changes (false), externally_visible (false),
-      no_reorder (false), force_output (false), forced_by_abi (false),
+      no_reorder (false), force_output (optimize), forced_by_abi (false),
       unique_name (false), implicit_section (false), body_removed (false),
       used_from_other_partition (false), in_other_partition (false),
       address_taken (false), in_init_priority_hash (false),

or in a more suitable place.  That should eventually also avoid
promotion to local.

> > some of the transforms are unavoidable due to partitioning(?) but we could
> > default to 1:1 partitioning at -O0 ...
> 
> At this point I'm not interested in defaults yet. I can achieve 1:1
> partition by testing target board unix/-flto/-flto-partition=1to1.
> 
> For now I'm interested in a combination of flags that exercises the specific
> type of debug info generation as is done for lto, without actually doing any
> optimizations.
> 
> F.i., an open question for me is the following: I'm now using
> -flto-partition=none for testing, but maybe 1to1 should yield better results?

[Bug middle-end/51663] Desirable/undesirable elimination of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tom de Vries from comment #13)
> F.i., an open question for me is the following: I'm now using
> -flto-partition=none for testing, but maybe 1to1 should yield better results?

I guess it better mimics how the testcases are set up, but I think the
differences will be due to the other issues so the exact partitioning
shouldn't matter (you likely always get a single partition and thus
behavior equal to -flto-partition=none or -flto-partition=one by default).
-flto-partition=none will be faster because it elides the LTRANS IL streaming.