[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
We are able to do the LIM at -O3 which enables loop unswitching.
I wonder if there is a way to enable a limited form of loop unswitching for -O2
where one branch of the loop to unswitch is empty.

[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Unswitching does this as a separate transform now, the "hoist guards"
transform.
It's even done completely separate now:

unsigned int
tree_ssa_unswitch_loops (function *fun)
{   
  bool changed_unswitch = false;
  bool changed_hoist = false;
  auto_edge_flag ignored_edge_flag (fun);

  ranger = enable_ranger (fun);

  /* Go through all loops starting from innermost, hoisting guards.  */
  for (auto loop : loops_list (fun, LI_FROM_INNERMOST))
    { 
      if (loop->inner)
        changed_hoist |= tree_unswitch_outer_loop (loop);
    }

  /* Go through innermost loops, unswitching on invariant predicates
     within those.  */
...

the question is how we'd call the "cheap" unswitching transform.  I guess
simply testing optimize > 2 || opt_enabled or so isn't quite desirable.

Note it's possible to separate this into an entirely separate pass as well.

[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

[rakdver at gcc dot gnu dot org]

------- Additional Comments From rakdver at gcc dot gnu dot org  2005-09-20 13:33 -------
k*stridev?[2] cannot be moved more at the moment.  The loops looks like

for (k = ...)
  for (j = ...)
    {
      if (i >= i1)
        continue;
      do
        {
          tmp = k * stridevx[2];
          ...
        }  while (i < i1)
    }

Note that if i >= i1, the load of stridevx[2] is never executed.  And it is
possible that it will trap.  Thus, we can only move it to point where we are
sure that we do not make it executed unconditionally.  I.e. it is legal to move
it out of the innermost loop, but not out of the outer ones.

There are two optimization improvements that could help (and as this case is
fairly common, I will leave this PR open as an enhancement request).

The first optimization is predicated invariant motion.  I.e. we cannot move
stridevx[2] out of the second loop, but we can move the expression (i < i1 ?
stridevx[2] : undefined) out of it, and it has the same value in all interesting
cases.

The second optimization is invariant exit motion. I.e. we can replace

do
  {
     code1;
     if (invariant)
       break;
     code2;
  } while (something);

with

if (invariant)
  {
    code1;
  }
else
  {
    do
      {
         code1;
         code2;
      } while (something);
  }

This could be achieved through loop unswitching (for non-innermost loops), or as
a separate optimization.  Note however that for this optimization to be useful
for invariant motion, it would either have to be iterated with it, or, at the
expense of significant complications, to be implemented within invariant motion.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-09-20 13:33:54
               date|                            |


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

[Bug tree-optimization/23970] loop-invariant-motion is not doing it's work

[rguenth at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at atrey dot karlin
                   |                            |dot mff dot cuni dot cz


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