[Bug tree-optimization/37239] New: peeling last iteration of a <= loop

[Bug tree-optimization/37239] New: peeling last iteration of a <= loop

[bonzini at gnu dot org]

If the condition of the loop is tested within the loop with == or !=, it may be
beneficial to peel off the final iteration of the loop by changing the
condition to <.

This happens in the attached benchmark's heapsort function where

    while ((maxIdx += maxIdx) <= last) { 
        if (maxIdx != last && numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++;
        if (tmp >= numbers[maxIdx]) break;
        numbers[top] = numbers[maxIdx];
        top = maxIdx;
    }

can become

    while ((maxIdx += maxIdx) <= last) { 
        if (numbers[maxIdx] < numbers[maxIdx + 1]) maxIdx++;
        if (tmp >= numbers[maxIdx]) break;
        numbers[top] = numbers[maxIdx];
        top = maxIdx;
    }
    if (maxIdx == last && tmp < numbers[maxIdx]) {
        numbers[top] = numbers[maxIdx];
        top = maxIdx;
    }

enabling in turn if-conversion of the first branch.

Performance of the benchmark is (-O3)

    basic               2.990
    peeling only        2.730
    if-conversion only  2.290
    peel+if-convert     2.010   (faster than quicksort!!)

ICC does this optimization.


-- 
           Summary: peeling last iteration of a <= loop
           Product: gcc
           Version: 4.3.2
            Status: UNCONFIRMED
          Keywords: missed-optimization
          Severity: normal
          Priority: P3
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: bonzini at gnu dot org


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

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[bonzini at gnu dot org]

------- Comment #1 from bonzini at gnu dot org  2008-08-26 11:36 -------
Created an attachment (id=16148)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16148&action=view)
benchmark


-- 


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

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[rguenth at gcc dot gnu dot org]

------- Comment #2 from rguenth at gcc dot gnu dot org  2008-08-27 11:58 -------
Hm, I don't know if the loop optimization code can peel the last iteration.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org, rakdver at gcc dot gnu
                   |                            |dot org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-27 11:58:09
               date|                            |


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

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[bonzini at gnu dot org]

------- Comment #3 from bonzini at gnu dot org  2008-08-27 12:08 -------
no, it does not and I think it should not except for this particular case (or
other similar ones).


-- 


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

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |enhancement


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

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |26163
      Known to fail|                            |

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
There is another case where this optimization can come into handy and shows up
in SPEC 2006.:

for (i = 1; i <= N; i++)
{
  ...
  if (i < N)
  {
    ...
  }
}

This is inside hammer's inner most loop.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k and 2k6 and 95)

[Bug tree-optimization/37239] peeling last iteration of a <= loop

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
lsplit reports:
Found potential split point: if (maxIdx_171 <= qty_7)
 { i_6 * 2 + I*-2 } le_expr qty_7

But nothing else ...