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: [PATCH 1/6] RTL & dwarf2out changes


On Mon, Jul 28, 2014 at 11:48:58AM -0700, Cary Coutant wrote:
> > +  /* ??? MD5 of another hash doesn't make a lot of sense... */
> > +  hash = hstate.end();
> >    CHECKSUM (hash);
> 
> [citation needed] I don't see why you think that. Maybe it'd be nicer
> if we could use hash_loc_operands() to feed its input directly into
> the MD5 checksum, but I think in this case it's perfectly fine to use
> the hash instead, in order to avoid reimplementing a rather
> substantial function that already exists.

Well you're dropping information at least, and it's slower
than it could be.

> Maybe we could make hash_loc_operands() a template that can be used as
> part of either inchash or MD5?
> 
> In the case of loc_checksum(), we're tied to MD5 by the DWARF
> standard. Otherwise, we could just rewrite it to use inchash
> throughout.

I'm not sure I understand the motivation. If gcc hashes in
gcc specific stuff (and this hash, even before my changes is)
then the output can never be re-created by anything but gcc.

If the standard just wants a well hashed number at the end
then any good hash should do.

I haven't checked it for this case, but if the hashing shows
up in profiles it may be worth using a faster but non secure
hash.

Anyways I can drop the comment if you don't agree with it.

-Andi


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