Lazy allocation of DECL_ASSEMBLER_NAME

Jan Hubicka hubicka@ucw.cz
Tue Mar 2 17:22:00 GMT 2004


> 
> >OK, so to summarize the sitaution, the conclusion is that the DECL nodes
> >shall be unique now and thus using DECL_ID indexed hash table shall be
> >safe?
> > 
> >
> Yes.  If there are problems with that, then we will need to fix the 
> front ends.
> 
> >Also I need to get nodes from identifier names back in varasm.c (while
> >outputting them).  Is there some comfortable way to get the DECLs back
> >without having two hashtables?
> > 
> >
> Not that I know of.  The real fix would be to change the interfaces so 
> that you had DECLs, rather than names, in varasm.c -- but I know that 
> would be a huge change.
> 
> >Would it be OK if I did it once the cgraph merge patch is settled down?
> > 
> >
> Yes.  We're not going to make this optimization for 3.4, and there is 
> lots of time until 3.5.
> 
> I'd really like to see you make progress on some of the wrong-code/ICE 
> bugs in 3.4.  For example, the cselib_record_set problems should be fixed.

Yes, I plan to work on them this week (I was traveline majority of last
week so didn't had much time for funny tasks like watching bugzilla) The
cselib_record_set is however pretty nasty old issue (not sure how I got
attached to that bug :).  I will probably try to make patch to avoid the
abort as RTH suggest but I think we can get various random
missoptimizations in presence of multiple sets of same destination in
single instruction...

Honza
> 
> Thanks,
> 
> -- 
> Mark Mitchell
> CodeSourcery, LLC
> (916) 791-8304
> mark@codesourcery.com



More information about the Gcc mailing list