This is the mail archive of the gcc@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: Is there really only one symbol_ref object referring to eachsymbolic label?


Hi Zack,

> > I was just playing with ggc_alloc_string and noticed the same.  When
> > gcc was put into cvs, ggc_alloc_string was in ggc-page.c and looked
> > like so.  I haven't found any trail of uniquization.
> 
> Check the earliest revisions of stringpool.c.
> 
> > Should we start using htab_*?
> 
> No, it should use hashtable.c.

I just started using hashtable.c for ggc_alloc_string with a hash
table separate from the one for identifiers.  If I compile combine.c,
ggc_alloc_string() is called only 294 times, out of which 157 are
unique.  What's the point of returning a unique string?  Some people
do use gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (...)), but doing so does
not really allow the comparison of two SYMBOL_REFs based on XSTR (x, 0)
unless every call to gen_rtx_SYMBOL_REF() goes through ggc_strdup().

By the way, if I do put ggc_strdup() in gen_rtx_SYMBOL_REF(), I find
176 duplicate strings out of 938 (in case of init-attrtab.c).  All of
the duplicates are *LCXXX, where XXX is a number.

Kazu Hirata


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