This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Is there really only one symbol_ref object referring to eachsymbolic label?
Kazu Hirata <kazu@cs.umass.edu> writes:
> 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().
I can't speak to the history here, but perhaps it would be a good
thing for the SYMBOL_REF itself to be uniquized. I can see more
benefits to that than to the present situation where only the string
is (supposed to be) unique. This would also require fewer
modifications to hashtable/stringpool.
By the way, SYMBOL_REF nodes whose string constants are identical to
identifiers are very common -- whatever you do, make sure we don't get
two copies of those.
zw