[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

2021-08-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2019-05-22 00:00:00 |2021-8-10
   Severity|normal  |enhancement

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

2019-05-23 Thread vittorio.romeo at outlook dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571

--- Comment #4 from Vittorio Romeo  ---
> I wonder how the "original" testcase looked
like - the one in this bug is probably simplified from real-world code?

This is what the original author of the code (Filipp Gelman) said:

> I was reviewing some code that checked configuration. The configuration 
> struct has several functions taking no arguments and returning bool. The 
> value of an enum determined which of these was called.
> I thought that the choice of which member function to call depends only on 
> the enum and not on anything else in the configuration, so I tried splitting 
> selecting the member function from calling it.
> This code looks much closer to what I reviewed: https://godbolt.org/z/L_W_oi
> The author wrote `test1`. I considered suggesting `test2`, but was surprised 
> by it not optimizing to the same code.

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

2019-05-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571

--- Comment #3 from Richard Biener  ---
Turning indirect calls into direct ones might be important enough to also
handle

int x, y;
int f() { return x; }
int g() { return y; }
int t0(bool b) { int (*i)() = b ?  :  x = 1; return i(); }
int main(int ac, char**) { return t0(ac & 1); }

like where there are statements before the indirect call that prevent it
from being simply duplicated into the predecessor blocks.

The transformation "primitive" would then be to duplicate the
joiner up to the call and the "interesting" part of it is
creating all required PHI nodes (unless you want to make SSA rewrite
deal with this somehow).  Sinking stmts below the call and limiting
the amount of copying is important.  Note there are related PRs for
that we miss to sink/hoist stmts through PHI nodes when that reduces the
number of PHI nodes.

The transform would likely split the block, insert "block-closed" PHI
nodes in the tail part for all SSA names defined in the first half and
live over the new edge and then duplicate the first half re-wiring
edges as needed.

This is as opposed to the original testcase where a simpler pattern-matching
scheme could be invented.  I wonder how the "original" testcase looked
like - the one in this bug is probably simplified from real-world code?

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

2019-05-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-22
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Let me try.

[Bug tree-optimization/90571] Missed optimization opportunity when returning function pointers based on run-time boolean

2019-05-22 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90571

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|c++ |tree-optimization

--- Comment #1 from Richard Biener  ---
I think there's a dup for this somewhere.  Basically we fail to optimize

  if (_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   :

   :
  # iftmp.0_10 = PHI 
  _11 = iftmp.0_10 ();

on the GIMPLE level.  It might be tempting to enable tree-ssa-phiprop.c to
transform this into

  if (_2 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   :
tem1 = f();
goto bb4;

  :
tem2 = g();

   :
  # iftmp.0_10 = PHI 
  _11 = iftmp.0_10;