[Bug tree-optimization/23619] Missed pre opportunity

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at gcc dot gnu dot org]

------- Comment #11 from dberlin at gcc dot gnu dot org  2005-12-15 15:04 -------
This should be fixed now with the PRE patches committed and the reassocpatches
committed.


-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at gcc dot gnu dot org]

------- Comment #12 from dberlin at gcc dot gnu dot org  2006-01-26 17:53 -------
Fixed


-- 

dberlin at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED


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

[Bug tree-optimization/23619] Missed pre opportunity

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.2.0


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

[Bug tree-optimization/23619] New: Missed pre opportunity

[rakdver at gcc dot gnu dot org]

On the following testcase:

int a[100];

void foo(int p, int q)
{
  int i;

  for (i = 0; i < 100; i++)
    if (i & 8)
      a[i] = (p + q) + 2;
    else
      a[i] = (p + q) + 4;
}

I expected (p+q) to be moved out of loop by pre, but it does not happen. At
first I thought this is caused by reassociation, which modifies the loop to

  for (i = 0; i < 100; i++)
    if (i & 8)
      a[i] = (p + 2) + q;
    else
      a[i] = (p + 4) + q;

But even with reassociation disabled, PRE does nothing.

-- 
           Summary: Missed pre opportunity
           Product: gcc
           Version: 4.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: tree-optimization
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rakdver at gcc dot gnu dot org
                CC: dberlin at gcc dot gnu dot org,gcc-bugs at gcc dot gnu
                    dot org
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug tree-optimization/23619] Missed pre opportunity

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-29 12:33 -------
This is a dup of bug 23286 and a couple other ones.

*** This bug has been marked as a duplicate of 23286 ***

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |DUPLICATE


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

[Bug tree-optimization/23619] Missed pre opportunity

[rakdver at gcc dot gnu dot org]

------- Additional Comments From rakdver at gcc dot gnu dot org  2005-08-29 12:46 -------
Is it really a duplicate? I think that in 23286, VUSE at ii may be the problem;
but in this testcase, there is nothing that can prevent p+q from being moved out
of loop.  Also, in the expression p + q is partially redundant over the back
edge of the loop, so PRE should work for it.

-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-29 12:53 -------
Yes it is a dup as, the issue is we don't pre things for:
if (a)
  d = b + c;
else
  d = b + e;

Where b is a complex expression (yes this is simplifing it).

Even pull the load of ii in PR 23286, we still don't get the PRE.

-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 13:40 -------
Subject: Re:  Missed pre opportunity



On Mon, 29 Aug 2005, pinskia at gcc dot gnu dot org wrote:

>
> ------- Additional Comments From pinskia at gcc dot gnu dot org  2005-08-29 12:53 -------
> Yes it is a dup as, the issue is we don't pre things for:
> if (a)
>  d = b + c;
> else
>  d = b + e;
>
> Where b is a complex expression (yes this is simplifing it).

As a general statement, this is true, but in a loop is different because 
it should be partially redundant over the backedge.

I'm tentatively with zdenek that we should be PRE'ing something here.
I'll look at the actual dumps :)


-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 15:15 -------
Subject: Re:  Missed pre opportunity

On Mon, 2005-08-29 at 12:46 +0000, rakdver at gcc dot gnu dot org wrote:
> ------- Additional Comments From rakdver at gcc dot gnu dot org  2005-08-29 12:46 -------
> Is it really a duplicate? I think that in 23286, VUSE at ii may be the problem;
> but in this testcase, there is nothing that can prevent p+q from being moved out
> of loop.  Also, in the expression p + q is partially redundant over the back
> edge of the loop, so PRE should work for it.
> 

Disabling reassoc, it knows that p + q is antic over the backedge.
Which means it knows it *could* insert it.
Why it's deciding not to do an insert is what i'm analyzing now.




-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 15:23 -------
Subject: Re:  Missed pre opportunity


> Disabling reassoc, it knows that p + q is antic over the backedge.
> Which means it knows it *could* insert it.

Okay, it determines it's not fully available in block 6, even though
both predecessors of 6 generate it, because neither predecessor strictly
dominates block 6, and nowhere else that generates the expression does.

This is a partial partial case that i never bothered handling because it
just doesn't happen often in practice, AFAICT.

We can do it, and i know how, it just was never worth it.

We'd have to generate a no-cost phi in block 6 to merge the two
available values.

Let me see if i can change compute_avail to do this for us so we don't
have to worry about it later.




-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 19:29 -------
not a dupe

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|DUPLICATE                   |


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at dberlin dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 19:31 -------
Subject: Bug 23619

Zdenek, the following patch (bootstrapping now) should fix your bug
23619.diff



------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 19:31 -------
Created an attachment (id=9617)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9617&action=view)


-- 


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

[Bug tree-optimization/23619] Missed pre opportunity

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2005-08-29 19:31 -------
mine

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |dberlin at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED
     Ever Confirmed|                            |1
   Last reconfirmed|0000-00-00 00:00:00         |2005-08-29 19:31:55
               date|                            |


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