This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)
- From: Trevor Saunders <tsaunders at mozilla dot com>
- To: Jan Hubicka <hubicka at ucw dot cz>
- Cc: Richard Biener <rguenther at suse dot de>, Mike Stump <mikestump at comcast dot net>, Jeff Law <law at redhat dot com>, Marek Polacek <polacek at redhat dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, "Joseph S. Myers" <joseph at codesourcery dot com>, Jakub Jelinek <jakub at redhat dot com>
- Date: Thu, 7 Aug 2014 14:28:35 -0400
- Subject: Re: [C PATCH] Discard P - (P + CST) optimization in pointer_diff (PR c/61240)
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot LSU dot 2 dot 11 dot 1408041404040 dot 20733 at zhemvz dot fhfr dot qr> <20140805143652 dot GG24292 at redhat dot com> <53E13B1D dot 5050401 at redhat dot com> <alpine dot LSU dot 2 dot 11 dot 1408060951390 dot 20733 at zhemvz dot fhfr dot qr> <634E36B1-4340-43B5-97F1-9C897D63306E at comcast dot net> <alpine dot LSU dot 2 dot 11 dot 1408070948560 dot 20733 at zhemvz dot fhfr dot qr> <20140807095515 dot GA11828 at tsaunders-iceball dot corp dot tor1 dot mozilla dot com> <20140807102934 dot GA25208 at kam dot mff dot cuni dot cz> <alpine dot LSU dot 2 dot 11 dot 1408071325170 dot 20733 at zhemvz dot fhfr dot qr> <20140807114402 dot GB4756 at kam dot mff dot cuni dot cz>
On Thu, Aug 07, 2014 at 01:44:02PM +0200, Jan Hubicka wrote:
> > It's only important to not inline the static constructor into the
> > one function calling all of them. And only not doing that during
> > early inlining (but still inline into those constructors). That's
> > because we eventually want to eliminate the body of the static
> > constructor in favor of a DECL_INITIAL in that new pass.
>
> I see, that indeed makes sense (and I was thinking of that).
> Disabling early inlining of static ctors seems OK, but we may
> not even need to do that given that we process topologically - so
> we will identify simple ctor before we inline it.
> (assuming we do not want to do this at LTO that would also make
> sense)
> >
> > So we need to be able to identify
> >
> > struct X { int i; X() { i = 1; } } a;
> >
> > _constructor_of_a ()
> > {
> > a.i = 1;
> > }
> >
> > and place 'a' into .data with the appropriate initialization.
> > And then remove a.i = 1
>
> Yeah, I think annotating cgraph nodes with info "this is static
> ctor of this variable" would be easy and we don't neven need to
> mess with the rest of C++ FE finalization code (i.e. one unifying
> it to static construction functions).
> Early inliner can skip inlining these if desirable and the new
> pass can easily identify them.
I'm not sure how you find the variable given a cgraph node, but if you
do great.
> Being able to turn stores into ctor is something that may be
> shareable with Martin's ipa-prop analysis.
that's handy, have a link?
> He is basically doing that IMO.
> >
> > Of course similar thing would be possible from the function
> > with all those constructors inlined but I guess it's much
> > harder if you may end up seeing calls inside (stuff may get
> > overwritten...).
> >
> > OTOH, I wonder if
> >
> > struct X { int i; X() { i = 1; } } a;
> > struct X { int i; X() { i = 1; a.i = 2; } } b;
> >
> > is well-defined (with proper constructor priority attribute
> > to init a last or without). That is, may we write to 'a'
> > from the constructor of b before it has been constructed?
>
> Hehe, not a question for me :)
I feel like the anser should be if you write to a global before its
I feel like it should only be valid to write to a global variable after
its initialized, but I really don't know what C++ says.
Trev
>
> Honza
> >
> > Richard.