The dead store problem seems to be a regression in SRA. In 4.4, the
struct with array is properly expanded in to scalars allowing copy
prop and dead code elimination -- in 4.5, this does not happen. You
should file a bug .
David
On Wed, Apr 21, 2010 at 7:30 PM, tbp <tbp...@gmail.com> wrote:
> Hello,
>
> having finally built myself a 4.5.0 (linux x86-64), i've quickly tried
> it on some of my code and it soon became apparent some things weren't
> for the better.
> Here's my febrile attempt to sum up what surprised me
> $ cat huh.cc
> #include <cmath>
> #if __GNUC__ * 100 + __GNUC_MINOR__ < 405
> #define constexpr
> #endif
> struct foo_t {
> float x, y, z;
> foo_t() {}
> constexpr foo_t(float a, float b, float c) : x(a),y(b),z(c) {}
> friend foo_t operator*(foo_t lhs, float s) { return foo_t(lhs.x*s,
> lhs.y*s, lhs.z*s); }
> friend float dot(foo_t lhs, foo_t rhs) { return lhs.x*rhs.x +
> lhs.y*rhs.y + lhs.z*rhs.z; }
> };
> struct bar_t {
> float m[3];
> bar_t() {}
> constexpr bar_t(float a, float b, float c) : m{a, b, c} {}
> friend bar_t operator*(bar_t lhs, float s) { return bar_t(lhs.m[0]*s,
> lhs.m[1]*s, lhs.m[2]*s); }
> friend float dot(bar_t lhs, bar_t rhs) { return lhs.m[0]*rhs.m[0] +
> lhs.m[1]*rhs.m[1] + lhs.m[2]*rhs.m[2]; }
> };
> namespace {
> template<typename T> float magsqr(T v) { return dot(v, v); }
> template<typename T> T norm(T v) { return v*(1/std::sqrt(magsqr(v))); }
> constexpr foo_t foo(1, 2, 3);
> constexpr bar_t bar(1, 2, 3);
> }
> void frob1(const foo_t &a, foo_t &b) { b = norm(a); }
> void frob2(const bar_t &a, bar_t &b) { b = norm(a); }
> int main() { return 0; }
> $ g++ -std=c++0x -O3 -march=native -ffast-math -mno-recip huh.cc
>
> a) Code produced for frob1 and frob2 differ (a dead store isn't
> removed with the array variant), when they used not to (for example
> with g++ 4.4.1); that's a really annoying regression (can't index
> foo_t members etc...).
> b) Note the rsqrtss in there: -ffast-math turns
> -funsafe-math-optimizations on which, now, also turns on
> -freciprocal-math; the old -m[no-]recip switch that used to direct the
> emission of reciprocals is useless; no warnings of any sort emitted.
> The only mention of the new behaviour is in the manual (nothing in
> http://gcc.gnu.org/gcc-4.5/changes.html).
> c) constexpr apparently makes no difference, stuff still gets
> constructed/stored at runtime. Vectors aren't allowed either: error:
> parameter '__vector(4) float v' is not of literal type; even if that's
> what the standard say, it would have been handy.
>
> Q:
> Is the dead store removal/fuss with arrays a known/transient issue
> soon to be fixed (again)?
> Would it be possible to foolproof
> -ffast-math/-freciprocal-math/-mrecip in some way?
> What's the deal with constexpr (or what can i reasonably expect)?
>
