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: [PATCH]: Interprocedural detection of readonly and non-addressablestatic 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.


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



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.


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