This is the mail archive of the gcc-patches@gcc.gnu.org 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: DECL_CALL_CLOBBERED tweek


> Jan Hubicka wrote on 12/21/06 10:11:
> 
> >If I get it right, your idea is basically:
> >
> >1) have one space for static DECL_UIDs
> >2) have separate space for each functions
> >
> No.  It's not that.  I meant the same scheme for *all* symbols.  Every 
> symbol will have a unique global UID made up of two numbers: The first 
> is for the CFUN where the symbol was generated (0, for symbols in global 
> scope).  The second is for the actual ID.
> 
> Every time function F generates a new symbol S, the UID for S is
> <FNID, LAST_ID[FNID]++>.  Or something to that effect.

Yep, I think we are mostly in agreement, just caling it differently.
You need to have toplevel stuff somewhere, such as FNID 0.
What I am bit concerned about is storing function local data
associated with toplevel variables.  If done using arrays, we will have
#functions*#toplevel vars memory consumption that might turn out to be
serous for LTO...

Sure, we can do things like arrays for function local stuff + hashtables
for such global stuff, but it is not much better than that what we have
right now (ie one dense UID space for each function, with static
variables having different UIDs).

Honza
> 
> So, to maintain symbol properties, we will need an array of arrays.  The 
> first dimension indicates the function, the second dimension is the 
> symbol entry.
> 
> I have not thought long about it, so I can't give you a good supporting 
> story for this.


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