[Bug optimization/14814] New: Dead stores not eliminated

[Bug optimization/14814] New: Dead stores not eliminated

[dalej at gcc dot gnu dot org]

The dead stores to the stack in foo are not eliminated until the RTL optimizers.
This is derived from the eon SPECmark, and similar constructs are common in C++.
13952 is related, but not the same.

class YY { public:
  YY(const YY &v) { e[0] = v.e[0]; e[1] = v.e[1]; e[2] = v.e[2]; }
  double &y() { return e[1]; }
  double e[3];  };

class XX { public:
  YY direction() const { return v; }
  YY v;  };

int foo(XX& r) {
  if (r.direction().y() < 0.000001) return 0;
  return 1; }

Here is a C variant (from Andrew Pinski) where the RTL optimizers aren't good enough:

struct YY {
  double e[3];  };

static inline double *y(struct YY* this_1) { return &this_1->e[1]; }

struct XX {
  struct YY v;
 };

static inline struct YY direction (const struct  XX* this_1) { return this_1->v;}

int foo(const struct XX* r) {
  struct YY t = direction(r);
  if (*y(&t) < 0.000001) return 0;
  return 1;
}

-- 
           Summary: Dead stores not eliminated
           Product: gcc
           Version: tree-ssa
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P2
         Component: optimization
        AssignedTo: dnovillo at gcc dot gnu dot org
        ReportedBy: dalej at gcc dot gnu dot org
                CC: gcc-bugs at gcc dot gnu dot org
 GCC build triplet: powerpc-apple-darwin7.2.0
  GCC host triplet: powerpc-apple-darwin7.2.0
                    powerpc-apple-darwin7.2.0
GCC target triplet: powerpc-apple-darwin7.2.0


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

[Bug optimization/14814] Dead stores not eliminated

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-04-01 23:34 -------
Confirmed.
This is almost a dup of bug 13952.
Some of it will be fixed when PR 13952 is fixed but there is still some other work to do with respect to 
casts and arrays.

Cannot scalarize variable <D1048> because it contains an aggregate type field, e<D1024>
Cannot scalarize variable retval.4<D1049> because it contains an aggregate type field, e<D1024>
Cannot scalarize variable T.1<D1038> because it contains an aggregate type field, e<D1024>

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
  BugsThisDependsOn|                            |13952
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|                            |1
   GCC host triplet|powerpc-apple-darwin7.2.0   |powerpc-apple-darwin7.2.0
                   |powerpc-apple-darwin7.2.0   |
                   |powerpc-ap                  |
           Keywords|                            |pessimizes-code
   Last reconfirmed|0000-00-00 00:00:00         |2004-04-01 23:35:02
               date|                            |
   Target Milestone|---                         |tree-ssa


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

[Bug rtl-optimization/14814] SRA does not happen on arrays in structs

[pinskia at gcc dot gnu dot org]

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|3.5.0                       |---


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

[Bug rtl-optimization/14814] no folding back to ARRAY_REF for COMPONENT_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-23 01:29 -------
I should note that the tree level still cannot handle the some of this but the RTL still can do it for some 
reason.
Note after my no-lower patches what needs to be folded this time is:
*((double *)&<D1601>.e + 8B)
into
<D1601>.e[1]

Simpler example for the problem now:
struct YY {
  double &y() { return e[1]; }
  double e[3];  };

double foo(YY& r) {
return r.y();
}
double foo1(YY &r)
{
  return r.e[1];
}
The tree expressions should be the same for foo and foo1.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2004-06-29 17:31:54         |2004-08-23 01:29:42
               date|                            |
            Summary|SRA does not happen on      |no folding back to ARRAY_REF
                   |arrays in structs           |for COMPONENT_REF


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF for COMPONENT_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-23 03:21 -------
Here is what the two functions have at .t34.dom2:
  T.1_3 = &r_1->e;
  T.2_4 = (double *)T.1_3;
  T.4_5 = T.2_4 + 8B;
  T.3_7 = *T.4_5;
--------
  T.5_2 = r_1->e[1];

if we could fold the first one into the second, we could fix this bug as we then prograte the constant 
and remove the dead code as we know longer need the struct living in memory at all.

-- 


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF for COMPONENT_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-23 04:13 -------
I should note that is related to bug 17141.

-- 


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF for COMPONENT_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-08-25 22:19 -------
I should point out that this fixes like 90% of the missed optimizations in eon alone.

-- 


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-01 00:50 -------
Really we don't do it for any kind of variable, even DECLs, see 17165 for another example of where the 
folding back does not happen and we actually don't vectorize the loop because of it.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|no folding back to ARRAY_REF|no folding back to ARRAY_REF
                   |for COMPONENT_REF           |


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-03 09:34 -------
Mine, I have a patch which fixes this.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|dnovillo at gcc dot gnu dot |pinskia at gcc dot gnu dot
                   |org                         |org
             Status|NEW                         |ASSIGNED


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2004-09-15 04:46 -------
This one has been fixed now, I think by:
2004-09-13  Richard Henderson  <rth@redhat.com>

        PR tree-opt/10528
        * tree-inline.c (copy_body_r): Recompute bits for ADDR_EXPR,
        after copying its argument.


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|---                         |4.0.0


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-05-17 16:33 -------
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01726.html

Further helps this situation in both testcases referenced below.  Basically
it removes the unwanted ADDR_EXPRs earlier in the optimization path.  While the
resulting assembly code is unchanged for these testcases, it does make a noticable
improvement on other codes (and speeds up the compiler).

-- 


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[jsm28 at gcc dot gnu dot org]

------- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-18 20:37 -------
The new test pr14814.C is failing on mainline, 20050518, all or most platforms.

FAIL: g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0


-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jsm28 at gcc dot gnu dot org
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[pinskia at gcc dot gnu dot org]

------- Additional Comments From pinskia at gcc dot gnu dot org  2005-05-18 20:44 -------
The test is still working correct and this was actually fixed really for 4.0.0, please open a new bug for 
the testcase problem because it is a new test.

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


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[joseph at codesourcery dot com]

------- Additional Comments From joseph at codesourcery dot com  2005-05-18 20:51 -------
Subject: Re:  no folding back to ARRAY_REF

On Wed, 18 May 2005, pinskia at gcc dot gnu dot org wrote:

> The test is still working correct and this was actually fixed really for 4.0.0, please open a new bug for 
> the testcase problem because it is a new test.

Could you please give your more detailed reasoning for why you think the 
problem is fixed and the testcase is defective?  If the test for a bug 
fails as soon as it is added, that is prima facie evidence that the bug is 
*not* fixed.



-- 


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[pinskia at physics dot uc dot edu]

------- Additional Comments From pinskia at physics dot uc dot edu  2005-05-18 21:00 -------
Subject: Re:  no folding back to ARRAY_REF


On May 18, 2005, at 4:51 PM, joseph at codesourcery dot com wrote:

>
> ------- Additional Comments From joseph at codesourcery dot com  
> 2005-05-18 20:51 -------
> Subject: Re:  no folding back to ARRAY_REF
>
> On Wed, 18 May 2005, pinskia at gcc dot gnu dot org wrote:
>
>> The test is still working correct and this was actually fixed really 
>> for 4.0.0, please open a new bug for
>> the testcase problem because it is a new test.
>
> Could you please give your more detailed reasoning for why you think 
> the
> problem is fixed and the testcase is defective?  If the test for a bug
> fails as soon as it is added, that is prima facie evidence that the 
> bug is
> *not* fixed.

Because the bug was actually fixed in 4.0.0 and the testcase was just 
added
yesterday.

Thanks,
Andrew Pinski



-- 


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

[Bug tree-optimization/14814] no folding back to ARRAY_REF

[law at redhat dot com]

------- Additional Comments From law at redhat dot com  2005-05-18 21:17 -------
Subject: Re:  no folding back to ARRAY_REF

On Wed, 2005-05-18 at 20:37 +0000, jsm28 at gcc dot gnu dot org wrote:
> ------- Additional Comments From jsm28 at gcc dot gnu dot org  2005-05-18 20:37 -------
> The new test pr14814.C is failing on mainline, 20050518, all or most platforms.
> 
> FAIL: g++.dg/tree-ssa/pr14814.C scan-tree-dump-times &this 0
Yea.  I know.  We may be better off xfailing this given the code we get
from FRE and the conservative handling of ADDR_EXPRs with multiple
uses in the forward propagator (that was a late change and I didn't
adjust the new test accordingly).

jeff




-- 


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