[PATCH]: Interprocedural detection of readonly and non-addressable static variables

Kenneth Zadeck zadeck@naturalbridge.com
Wed Jun 8 20:08:00 GMT 2005


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.

kenny



More information about the Gcc-patches mailing list