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; }
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>
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.
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.
I should note that is related to bug 17141.
I should point out that this fixes like 90% of the missed optimizations in eon alone.
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.
Mine, I have a patch which fixes this.
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.
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).
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
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.
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.
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
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