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