This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Symtab cleanup 10/17 remove unnecesary DECL_ARGUMENTS and DECL_RESULT

On Tue, Sep 3, 2013 at 3:42 PM, Jan Hubicka <> wrote:
>> > The decision what should go to local or global stream is basically motivated by
>> >   1) everything needed for interprocedural optimization has to be global
>> >   2) everything related to function bodies should be local.
>> I'd rather formulate it as "everything not needed at WPA time should be
>> local if it can be local"
> OK.  With additional rule that we want to have at least something local,
> or the local sections are pointless.
>> > For tree nodes, the decision about where the node goes is made by
>> > tree_is_indexable.  The current set of rules is
>> >  - parm_decl/result_decl is local
>> >    (before my change resut_decl was global and parm_decl was local, why those
>> >     was not the same escapes me, but it needed ugly fixup in ipa-prop that
>> >     needed to reconnect global DECL pointers to local DECL pointers after
>> >     streaming in)
>> >  - function variables are local if they are not static.
>> >    (Even external declarations are local, not only automatic vars.)
>> >  - Types are global unless they are variably modified types
>> >    (The variably modified type code walks into subtypes, so even pointers
>> >    to variably modified type are local or function declarations mentioning
>> >    these.)
>> >  - FIELD_DECL is global unless it is part of variably modified type.
>> >  - SSA_NAME is local despite logic of tree_is_indexable because it is handled
>> >    separately as part of gimple and gimple is always local.
>> >  - LABEL_DECLs are global even when their address is not taken and it would make
>> >    more sense to hide it in the body sections
>> >
>> > Now I think we are safe only when our references never violate A) and B) and moreover
>> > C) same entity that needs to be unique (such as declarations by one decl rule
>> >    or BLOCK) is not streamed into multiple streams.  We never merge things
>> >    between streams and duplicating those is forbidden by design.
>> >
>> > It is an irritating property of our streaming machinery that it is not
>> > diagnozing violations of A/B/C. Violations of type A and B are basically hidden
>> > by introducing violations of type C and compiler tends to be resistant to those
>> > in a sense that is usually does not ICE.
>> Yes, and with the re-organized streaming we can now do much better and
>> much faster!  This is because with the SCC finding we can record in O(SCC size)
>> whether a) the SCC contains entities that are local (and to what function) or
>> global, b) the SCC refers to other SCCs that are local (and in what function)
>> We can then detect whether we run into the situation that the new SCC refers
>> to SCCs that are in different local sections (which would mean those
>> SCCs in turn
>> would need to be globalized or that the current SCC needs to be duplicated into
>> all local sections it refers to).
>> I would not be surprised if our current tree structures, when strictly following
>> restrictions A) and B) would need to be either all global or all duplicated into
>> the local sections :/
>> At least we can now more easily formalize this (and can compute
>> "scc_is_indexable" which is the property we need now)
> I did not think of this.  SCC code can definitely help us to not put into local
> section an SCC component that contains something that needs to be global.  This
> is pretty cool in a way that tree_is_indexable don't need to do the closure
> itself (as it does for variadic types currently).
> I think the common case however is that you have variable A that is local.  SCC
> streaming will make it local since it see no must be global entities in that
> var.  Later you stream separate SCC component containing a type whose size
> depends on A.  SCC already made A local and you get a violation.

You get a violation if you cannot make the separate SCC local in the same
section as A or global.  Once the separate SCC refers to a local entity it
has to be local itself.  The only problem is if it refers to two local entities
in different local sections ... in which case we need to duplicate (or figure
out a way to break one of the references).

>> > Another alternative I can think of is to declare duplication in between streams
>> > sane and allowed, but teach streaming in code to patch in the in-memory
>> > representation from global stream by local stream one when this happens.  It
>> > seems bit tricky to implement - the decl states of functions would need to
>> > explicitly record the duplications in between local and global streams.
>> I think duplication is what we do right now, otherwise we couldn't fill in all
>> tree references at streaming time.
> Yes, we duplicate and that leads to illformed IL.
>> What we need to do is compute the decision once per SCC during the
>> SCC build and record statistics on how many trees we'll duplicate that
>> way (not sure if we even properly duplicate them now with the SCC streaming ...)
> Except that we need plan for the scenario above.

Change the tree layout ;)


> Honza
>> Richard.
>> > Honza

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]