[Bug tree-optimization/15559] New: SSAPRE misses obivous redudent expression

[Bug tree-optimization/15559] New: SSAPRE misses obivous redudent expression

[pinskia at gcc dot gnu dot org]

int f(int i, int b, int *c)
{
  int ii;
  if (b)
   ii = i +1;
  else
   {
     *c = ii = i+1;
   }
  return ii;
}

Note I added compile time hog and memory hog as this causes too many bb to be there 
and more RTL than needed.

-- 
           Summary: SSAPRE misses obivous redudent expression
           Product: gcc
           Version: 3.5.0
            Status: UNCONFIRMED
          Keywords: memory-hog, compile-time-hog, TREE
          Severity: enhancement
          Priority: P2
         Component: tree-optimization
        AssignedTo: dberlin at gcc dot gnu dot org
        ReportedBy: pinskia at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obivous redudent expression

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-05-21 12:35 -------
Confirmed, but I don't see it happening at the RTL level either in 3.5.0, so 
I'll remove the TREE keyword.

The optimization did happen with 2.95.3 though. I'll mark it as a regression, 
even if I expect only a tree-level solution to happen (maybe already with 
GCSE), so it won't probably be fixed for the 3.3 branch or 3.4 branch.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |critical
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
           Keywords|TREE                        |missed-optimization
      Known to fail|                            |3.5.0 3.0.4 3.2.2
      Known to work|                            |2.95.3
   Last reconfirmed|0000-00-00 00:00:00         |2004-05-21 12:35:35
               date|                            |
            Summary|SSAPRE misses obivous       |[3.3/3.4/3.5 Regression]
                   |redudent expression         |SSAPRE misses obivous
                   |                            |redudent expression
   Target Milestone|---                         |3.5.0


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obivous redudent expression

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-05-21 12:36 -------
(In reply to comment #1)

> (maybe already with GCSE)
                      ^^^^ I meant GVN-PRE



-- 


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obivous redudent expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-21 12:59 -------
I had forgot to say it works on powerpc-apple-darwin with all compilers so that is why I had TREE there.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|                            |powerpc-apple-darwin
           Keywords|                            |TREE


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obivous redudent expression

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-05-21 13:07 -------
I should note that it does happen at -Os on x86-pc-linux-gnu.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obvious redundant expression

[gdr at integrable-solutions dot net]

------- Additional Comments From gdr at integrable-solutions dot net  2004-05-21 14:47 -------
Subject: Re:  [3.3/3.4/3.5 Regression] SSAPRE misses obivous redudent expression

"giovannibajo at libero dot it" <gcc-bugzilla@gcc.gnu.org> writes:

| even if I expect only a tree-level solution to happen (maybe already with 
| GCSE), so it won't probably be fixed for the 3.3 branch or 3.4 branch.

yes, you're right about 3.3.x.

-- Gaby


-- 


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obvious redundant expression

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-05-22 00:08 -------
This should be fixed in GVNPRE.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2004-05-21 12:35:35         |2004-05-22 00:08:45
               date|                            |


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obvious redundant expression

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-06-10 16:05 -------
Actually, i'm not sure what you expect to happen here.
We won't hoist this because there is no point in hoisting this, it doesn't reduce the total number of 
computations along any path, but does increase the lifetime.
There is nothing redundant along any single path in the program.


-- 


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obvious redundant expression

[giovannibajo at libero dot it]

------- Additional Comments From giovannibajo at libero dot it  2004-06-10 16:12 -------
yes, but if GVNPRE hoists the operation, we end up with:

int f(int i, int b, int *c)
{
  int ii;
  ii = i+1;
  if (b)
    ;
  else
    *c = ii;
  return ii;
}

that can be later simplified to:

int f(int i, int b, int *c)
{
  int ii;
  ii = i+1;
  if (!b)
    *c = ii;
  return ii;
}


-- 


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] SSAPRE misses obvious redundant expression

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-06-10 16:45 -------
Theoretically yes, but no PRE algorithm will do what you suggest, you need a generic code hoisting 
algorithm.  The transformation you suggest violates the optimality conditions of PRE, even if it can later 
make better code, so it wouldn't be performed.
In short, PRE is for partial redundancies, not a cost based generic code hoister, so this is not a case of 
PRE missing obvious redundant expressions. There is no redundant expression (it occurs once along 
each path) here that it could eliminate, there is simply an expression that could be hoisted one block 
up.

-- 


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

[Bug tree-optimization/15559] [3.3/3.4/3.5 Regression] misses opportunity for hoisting an expression that would simplify control flow

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |minor
   Last reconfirmed|2004-05-22 00:08:45         |2004-07-09 03:53:14
               date|                            |


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-11-15 02:17 -------
An example of where not doing hurts:
  int ii;
int f(int i, int b, int *c)
{
  if (b)
   ii = i +1;
  else
   {
     *c = ii = i+1;
   }
  return ii;
}

As there is a store to ii and then a load from it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|powerpc-apple-darwin        |


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-11-15 07:53 -------
Not a hog, just a missed optimization. 
 
Let's reserve the *hog keywords for *real* hogs... 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|compile-time-hog, memory-hog|


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-11-23 02:49 -------
(In reply to comment #10)
> An example of where not doing hurts:
>   int ii;
> int f(int i, int b, int *c)
> {
>   if (b)
>    ii = i +1;
>   else
>    {
>      *c = ii = i+1;
>    }
>   return ii;
> }
> 
> As there is a store to ii and then a load from it.


I'm not sure what you are talking about.
At the tree level,  there is only a store.


-- 


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[dberlin at gcc dot gnu dot org]

------- Additional Comments From dberlin at gcc dot gnu dot org  2004-11-23 02:53 -------
(In reply to comment #8)
> yes, but if GVNPRE hoists the operation, we end up with:
> 
> int f(int i, int b, int *c)
> {
>   int ii;
>   ii = i+1;
>   if (b)
>     ;
>   else
>     *c = ii;
>   return ii;
> }
> 
> that can be later simplified to:
> 
> int f(int i, int b, int *c)
> {
>   int ii;
>   ii = i+1;
>   if (!b)
>     *c = ii;
>   return ii;
> }
> 

This is still not faster code, only smaller code.
And you'll note that with -Os, this is what we do.


In any case, i have no plan sto make GVN-PRE do this type of hoisting, as i'm
not so interested in code size.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dberlin at gcc dot gnu dot  |unassigned at gcc dot gnu
                   |org                         |dot org
             Status|ASSIGNED                    |NEW


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2004-12-12 00:06 -------
Gosh, I don't even see how this is a regression.  Geez.  Come on guys.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P2                          |P3


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[steven at gcc dot gnu dot org]

------- Additional Comments From steven at gcc dot gnu dot org  2005-01-21 13:46 -------
Mark, can we move the milestone on this one please?  There is no way 
this will be fixed for GCC 4.0. 
 

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mark at codesourcery dot com


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

[Bug tree-optimization/15559] [3.3/3.4/4.0 Regression] misses opportunity for hoisting an expression that would simplify control flow

[mmitchel at gcc dot gnu dot org]

------- Additional Comments From mmitchel at gcc dot gnu dot org  2005-01-21 17:12 -------
I'm going to go a step further and mark this INVALID.

Since we already do the right thing at -Os, and there's no evidence that we're
actually generating slower code at -O2, I'm not worried about this issue.  If
there's evidence that the code we're generating is slower than with a previous
compiler, post assembly code and timing information that shows that.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID


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