On Wed, 6 Aug 2014, Mike Stump wrote:

> On Aug 6, 2014, at 12:56 AM, Richard Biener <rguent...@suse.de> wrote:
> >> My concern is the code we're removing discusses the need to simplify when
> >> these expressions are in static initializers.  What's going to ensure that
> >> we're still simplifying instances which appear in static initializers?  I
> >> don't see anything which tests that.   And does it still work for targets
> >> which utilize PSImode?
> > 
> > You mean stuff like
> > 
> > int i[4];
> > const int p = i - (i + 2);
> 
> No.
> 
>   long p = i - (i + 2);
> 
> in C++.  It is valid and so it has to work.  Further, there is a well known 
> problem that if you get all the constants correct, you get to statically 
> initialize this and have no constructors.  Though the above is trivial, in 
> large C++ source bases, there is an important set of things that one must do 
> to hit expected quality.  Fold, fold, fold is the name of the game, and if 
> you do it well, you get app startup time that is short, and if you don’t do 
> it well, you get app startup time that sucks.  Some folks care about startup 
> time.  So for example, there are well known pdf viewers that use gcc to 
> compile and whose startup time would be a order of magnitude or more worse if 
> gcc didn’t optimize it as well as it does.  There are large OS vendors that 
> had:

It always works - you eventually get a runtime constructor though.

>       -Wglobal-constructors
>           Warn about namespace scope data that requires construction or 
> destruction, or functions that use the constructor
>           attribute or the destructor attribute.  Additionally warn if the 
> Objective-C GNU runtime is used to initialize
>           various metadata.
> 
> and used it to ensure (-Werror) that no constructors would sneak in anyplace, 
> as the corporate guide was no, you don’t get to do that.  Exceptions are made 
> and really, the main thing that hurt the most were libraries that users might 
> use, but you get the idea.
> 
> The right way to think of the cost was page faults proportional to the size 
> of the app, or, 0.  Pages faults turn out to be rather expensive as the core 
> speed of the processor is rather fast.  I know sounds overly expensive, but 
> that is my experience with Ado.., oops, I mean, with one critical customer.
> 
> Now, what do you have to do to get it right, evaluate all constant things 
> including constructors and destructors and be able to do this for a class 
> hierarchy.  We didn’t do if and while, but it would have been nice to do 
> those.  Things like:
> 
> class B {
>   int k;
>   B(int i) {
>     k = i;
> }
> 
> class A :public B {
>   int i;
>   int j;
>   A () :i (1) b(5) {
>     j = 5;
>   }
> } a;
> 
> not that demanding…  Note, I tried the code at the top, and gcc generate 
> runtime code for it.  :-(  Ouch.  clang does this:
> 
> _p:
>       .quad   -2                      ## 0xfffffffffffffffe
> 
> Ah.  I’d like to think that used to work at one point.

Probably not ;)

But seriously it's a matter of a) keeping constructors for each
variable separate and optimize them in GIMPLE, b) recognize
resulting code that can be expressed with a initializer

a) can be done with delaying inlining to IPA time and hoping
that early opts do enough to perform the necessary simplification,
b) needs a new pass (but I guess it shouldn't be _that_ hard...)

I think we already have constructor functions marked specially,
hopefully with a link to the initialized variable.

Richard.

Reply via email to