[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2024-04-09 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

--- Comment #4 from Mikael Morin  ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.

Here is a minimal revert of the regressing revision, but it may just make the
problem latent.

diff --git a/gcc/gimple-range-phi.cc b/gcc/gimple-range-phi.cc
index 01900a35b32..9fa9fe83ce0 100644
--- a/gcc/gimple-range-phi.cc
+++ b/gcc/gimple-range-phi.cc
@@ -386,14 +386,6 @@ phi_analyzer::process_phi (gphi *phi)
  m_work.safe_push (arg);
  continue;
}
- // More than 2 outside names is too complicated.
- if (m_num_extern >= 2)
-   {
- cycle_p = false;
- break;
-   }
- m_external[m_num_extern] = arg;
- m_ext_edge[m_num_extern++] = gimple_phi_arg_edge (phi_stmt, x);
}
  else if (code == INTEGER_CST)
{
@@ -402,12 +394,15 @@ phi_analyzer::process_phi (gphi *phi)
wi::to_wide (arg));
  init_range.union_ (val);
}
- else
+ // More than 2 outside names/CONST is too complicated.
+ if (m_num_extern >= 2)
{
- // Everything else terminates the cycle.
  cycle_p = false;
  break;
}
+
+ m_external[m_num_extern] = arg;
+ m_ext_edge[m_num_extern++] = gimple_phi_arg_edge (phi_stmt, x);
}
 }

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2024-04-09 Thread mikael at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #3 from Mikael Morin  ---
pre replaces usages of the 'e' global with a set of 'pretmp' and 'prephitmp'
ssa registers.

With gcc-13, the value of 'e' is reloaded directly after the call to 'foo',
and that value is joined with a phi in the next bb:

   [local count: 7761689018]:
  foo ();
  pretmp_25 = e;
  goto ; [100.00%]

...

   [local count: 8963573811]:
  # j_28 = PHI <1(10), j_30(24), 1(22), j_30(25), 1(26), j_30(20)>
  # i_29 = PHI 
  # prephitmp_38 = PHI 
  d.7_22 = d;
  _23 = d.7_22 + 1;
  d = _23;
  if (_23 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]


With gcc-14, the value of 'e' is reloaded later in the next bb, causing a
dependency on 'e', even on paths not calling 'foo':

   [local count: 7761689018]:
  foo ();
  goto ; [100.00%]

...

   [local count: 8963573796]:
  # i_28 = PHI 
  d.7_22 = d;
  _23 = d.7_22 + 1;
  d = _23;
  pretmp_10 = e;
  if (_23 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]


Later on this prevents copyprop from simplifying the 'pretmp' and 'prephitmp'
values to 3 and remove the branch calling 'foo'.

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2024-03-07 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||law at gcc dot gnu.org

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2023-11-24 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

--- Comment #2 from Andrew Macleod  ---
It seems like we set 'e' to 3 immediately at the start:
   [local count: 1073741824]:
  e = 3;
  goto ; [100.00%]

and it is never changed again. However, when we load from 'e' later in the IL
   [local count: 9485263241]:
  e.1_6 = e;

we simply get varying. Is some pass suppose to propagate this?  This reminds me
of a few other regression PRs where we no longer propagate known values from
loads from memory into ssa-names.

If we knew that e.1_6 was '3', then the call to foo would be folded away as
never executable.

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2023-09-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-09-05
 Status|UNCONFIRMED |NEW

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2023-09-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

--- Comment #1 from Andrew Pinski  ---
The difference is the trunk can figure out the range for j_8:
PHI GROUP query for j_8 found : [irange] int [1, 1][8, 8] and adjusted original
range from :[irange] int [1, 1][8, 8] to :[irange] int [1, 1][8, 8]
Global Exported: j_8 = [irange] int [1, 1][8, 8] MASK 0x9 VALUE 0x8

But 13 can't:
Global Exported: j_8 = [irange] int [-INF, +INF] NONZERO 0x9

I have not looked into how 13 can remove the call to foo though.

[Bug tree-optimization/111293] [14 Regression] Missed Dead Code Elimination since r14-3414-g0cfc9c953d0

2023-09-05 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.0