[Bug tree-optimization/46957] New: http://blog.regehr.org/archives/320 Example 1

[Bug tree-optimization/46957] New: http://blog.regehr.org/archives/320 Example 1

[jakub at gcc dot gnu.org]

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

           Summary: http://blog.regehr.org/archives/320 Example 1
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: spop@gcc.gnu.org


void foo (void);
long a, b;
void
foo (void)
{
  int i;

  b = -1L;
  i = 0;
  while (i < 63)
    {
      b *= 2L;
      i++;
    }
  a = -(b + 1L);
}

doesn't have the loop optimized out, as we don't have {-1L, *, 2}_1 style
chrecs, only , +, style.  I wonder if we couldn't for << or multiplication by
power of two express {-1L, *, 2}_1 instead as -1L << ({0, +, 1}_1), or
for other multiplication, say {a, *, b}_1, as a * pow (b, {0, +, 1}_1) and use
that in compute_overall_effect_of_inner_loop etc. to sccp it.

Of course only if the resulting expression is cheap enough.

[Bug tree-optimization/46957] http://blog.regehr.org/archives/320 Example 1

[hubicka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.12.16 00:54:14
                 CC|                            |hubicka at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-16 00:54:14 UTC ---
In addtion to that, loop unroller heuristics can be improved to predict that
all the statement in the loop will be constant after peeing.  It is actualy not
that hard to do.

With this, we would fully unroll the loop in question.

[Bug tree-optimization/46957] http://blog.regehr.org/archives/320 Example 1

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-12-16 09:31:43 UTC ---
Indeed, that's another possibility, could handle even more complex expressions.
On the other side, it makes sense to do it only if the initial value is
constant and thus we can expect the result is constant too, otherwise we might
risk creating too expensive operation instead of the loop (especially when the
loop doesn't roll too many times).  And we'd need some peel limit for that too,
as for a couple of passes until optimizers clean stuff up we could increase
number of stmts a lot.

[Bug tree-optimization/46957] http://blog.regehr.org/archives/320 Example 1

[hubicka at gcc dot gnu.org]

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

--- Comment #3 from Jan Hubicka <hubicka at gcc dot gnu.org> 2010-12-16 12:11:26 UTC ---
Yep, it is more hack that proper solution for this particular problem. I
considered implementing this a while ago when I ran into problem that fixing
insn estimates affected unrolling negatively in many testsuite testcases
(previously loads/stores was for free that made us to unroll a lot of loop to
great amounts).

I've seen more complex instances similar to this (like cases where we indexed
by IV var constant array and used result to index another constant array), so I
think it is good idea to implement both solutions. Often important part of loop
gets constant after peeling.

Unroller already can produce a lot of statements since it has logic about what
statements are constant based on IVs and similar stuff, there is/was PR on
that.
We probably want simple hard limit on number of new statements introduced, like
1000.

[Bug tree-optimization/46957] http://blog.regehr.org/archives/320 Example 1

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
   Last reconfirmed|2018-04-22 00:00:00         |2021-8-10