This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH]: Interprocedural detection of readonly and non-addressable static variables
> Jan Hubicka wrote:
> >>>FUNCTION_DECL will be the largest DECL, and probably pretty close to the
> >>>current size (108 bytes).
> >>>
> >>>I'm guessing (92+ bytes) at this point.
> >>>
> >>>Most of the extra cost is flags, arguments tree, and result tree.
> >>>
> >>>
> >>>--Dan
> >>>
> >>>
> >>Yes but this is the correct place to put it. There will be one
> >>allocated for every function (at least at -O1 and above) and it does not
> >>not require any space for any other kind of decl.
> >>
> >
> >The problem is that you don't need IPA info for every function
> >declaration we ever produce. C++ frontend produce tons of dead
> >declarations and I think that you don't need the data at all for
> >function not having their bodies available, so we actually need the data
> >for quite small fraction of all function decls we ever produce.
> >We probably might get better around with variables if we had static
> >variable inherited from variable with some extra fields...
> >
> >Honza
> >
> >>kenny
> >>
> >>
> Jan,
>
> There are only so many places to put the pointer to this information.
>
> You did not want it in the cgraph. Also when it was there it turned out
> to be very expensive to go from the function decl to the cgraph node
> thru your hash table.
>
> I will agree that the var-ann is the wrong place, but that does not
> leave any other place except the function decl.
>
> Danny has suggested that it should go in the cgraph node, in a structure
> that would hold all of the persistent information from the ipa pass.
> But if it goes here, then we really should add a field in the function
> decl that points to the cgraph node so we can get rid of the very slow
> hash map since this is likely to be a hot path when people start using ipa.
This seems to make sense to me too. I am not sure if going from
hashtable is essential right now as we don't seem to burn any important
amount of cycles in this hashtable, but if Danny's changes are making
this easier, I think it is good change (as Danny observed, there is
little room left in current decl nodes when it comes to functions).
Finally realizing the struct function/cgraph node merge would probably
save one pointer, but I am not quite sure how precisely this should look
like (yet) :(
Anyway I guess it is not that importnat issue right now, we always can
change it once the patch is in and if we experience memory bloat...
Honza
>
> kenny