[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2023-01-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

Andrew Pinski  changed:

   What|Removed |Added

 CC||eric-bugs at omnifarious dot 
org

--- Comment #9 from Andrew Pinski  ---
*** Bug 108361 has been marked as a duplicate of this bug. ***

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2022-08-09 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

Andrew Pinski  changed:

   What|Removed |Added

 CC||witold.baryluk+gcc at gmail 
dot co
   ||m

--- Comment #8 from Andrew Pinski  ---
*** Bug 105360 has been marked as a duplicate of this bug. ***

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2021-07-20 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-03-04 Thread ppalka at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #7 from Patrick Palka  ---
Here's a simple C++ example using std::function that illustrates the same
thing.  The call to h below is optimized away, but two now-unused static member
functions _M_invoke and _M_manager remain in the optimized code.


#include 

int
m ()
{
  std::function h = [] (int i) { return i - 1; };
  return h (5);
}


-fdump-tree-optimized:
;; Function std::_Function_handler >::_M_invoke
(_ZNSt17_Function_handlerIFiiEZ1mvEUliE_E9_M_invokeERKSt9_Any_dataOi,
funcdef_no=1738, decl_uid=33290, cgraph_uid=651, symbol_order=654)

std::_Function_handler >::_M_invoke (const union
_Any_data & {ref-all} __functor, int & __args#0)
{
  ...
}
;; Function std::_Function_base::_Base_manager >::_M_manager
(_ZNSt14_Function_base13_Base_managerIZ1mvEUliE_E10_M_managerERSt9_Any_dataRKS3_St18_Manager_operation,
funcdef_no=1739, decl_uid=33254, cgraph_uid=652, symbol_order=655)

Removing basic block 7
Removing basic block 9
std::_Function_base::_Base_manager >::_M_manager (union
_Any_data & {ref-all} __dest, const union _Any_data & {ref-all} __source,
_Manager_operation __op)
{
  ...
}

;; Function m (_Z1mv, funcdef_no=1392, decl_uid=31150, cgraph_uid=311,
symbol_order=314)

m ()
{
   [local count: 1073741824]:
  return 4;

}

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-02-08 Thread m...@nieper-wisskirchen.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

--- Comment #6 from Marc Nieper-Wißkirchen  ---
Interestingly, the above code, slightly modified, exhibits another problem the
optimizer has:

void foo ();

static void c (void (*w) (void))
{
w ();
}

static void f ()
{
foo ();
}

static void *x = 

void g ()
{
c (x);
}

The only difference consists in that f is not completely trivial but calls some
external function. In this case, the code of f is not inlined in g, and we get
the non-optimal code (in x86-64 assembly):

f:
xorl%eax, %eax
jmp foo
g:
jmp f

I'm not sure whether I should file in another bug for this example.

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-02-08 Thread m...@nieper-wisskirchen.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

--- Comment #5 from Marc Nieper-Wißkirchen  ---
Here is a much simpler example, which exhibits the same behavior:

static void c (void (*w) (void))
{
w ();
}

static void f ()
{
}

static void *x = 

void g ()
{
c (x);
}

The compiler optimizes g to an empty procedure and removes that static variable
x from the output. However, it outputs the unused, static function f.

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-02-02 Thread m...@nieper-wisskirchen.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

--- Comment #4 from Marc Nieper-Wißkirchen  ---
P.S.: This issue showed up when I tried to analyze why no optimization is
happening in bug #89152.

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-02-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

--- Comment #3 from David Malcolm  ---
(In reply to David Malcolm from comment #2)
> happens when we're already running cgraph_node::expand on "h"
  ~~
"when we've already run", I meant to say

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-02-01 Thread dmalcolm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-02-01
 CC||dmalcolm at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from David Malcolm  ---
Indeed, the last elimination is happening too late.

At -O3:
 .040t.tailr1 converts the tail-recursion in "g" into a loop
 .076i.inline inlines "g" into "foo", but an initialization of a temporary with
"h" remains in "foo"
 .103t.dce2 eliminates that last use of "h".

With the "a * 2" -> "a" variant at -O3,
 .025t.einline inlines "g" into "foo", converting the tail recursion into a
loop
 .033t.fre1 eliminates the usage of "h"

cgraphunit.c:expand_all_functions happens at .090t ("fixup_cfg" and
siblings/descendants), so the elimination of the last "h" in .103t.dce2 happens
when we're already running cgraph_node::expand on "h" (whereas in the einline
variant, "h" has already been eliminated before
cgraphunit.c:expand_all_functions).

[Bug ipa/89139] GCC emits code for static functions that aren't used by the optimized code

2019-01-31 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89139

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 CC||marxin at gcc dot gnu.org
  Component|tree-optimization   |ipa
Version|unknown |9.0

--- Comment #1 from Richard Biener  ---
It's likely eliminating the last use too late.