> > 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. > > 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. Honza > > Richard. > > > Honza
