Bug 19726 - suboptimal constructor generated, consecutive stores should be done in a biggest mode
Summary: suboptimal constructor generated, consecutive stores should be done in a bigg...
Status: RESOLVED DUPLICATE of bug 23684
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 3.4.2
: P2 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: missed-optimization
: 53254 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-01-31 16:27 UTC by Yuri
Modified: 2012-05-06 04:53 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2006-07-19 16:39:25


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Yuri 2005-01-31 16:27:33 UTC
1. code below compiles into many instructions like "movl $0, 16(%eax)", should
have been "stosw" since all initializations are zeros. Even if one or two are
skipped in the middle still bulk stosw should be used.
2. Even when class E with external constructor uncommented this shouldn't change
since constructor can't change any data in C.

Yuri

----code----

class E {
//  int j;
  public: E();
};


class C {
  int h, i, j, k, l;
//  E e;
  int m, n, o, p, q, r, s, t, u, v;
public:
  C();
};

C::C() : h(0), i(0), j(), k(0), l(0), m(0), n(0), o(0), p(0), q(0), r(0), s(0),
t(0), u(0), v(0) { }
Comment 1 Andrew Pinski 2005-01-31 18:49:07 UTC
Confirmed, note this is either a front-end bug because the front-end produces multiple stores or a 
target bug for not combining those stores to one store string instruction.

Also if one initializer is missing it turns out it is undefined if you access that data.
Comment 2 Yuri 2005-01-31 22:02:11 UTC
actually I want to generalize it:
any situation in C++/C/Ada when many enough close (in memory) variables are
assigned the same value should use bulk "stos(b/w/l)". This should be applied as
part of optimization.
Comment 3 Andrew Pinski 2007-04-03 17:54:23 UTC

*** This bug has been marked as a duplicate of 23684 ***
Comment 4 Andrew Pinski 2012-05-06 04:53:43 UTC
*** Bug 53254 has been marked as a duplicate of this bug. ***