This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH 1/6] RTL & dwarf2out changes
- From: Andi Kleen <ak at linux dot intel dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Andi Kleen <andi at firstfloor dot org>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Mon, 28 Jul 2014 12:25:05 -0700
- Subject: Re: [PATCH 1/6] RTL & dwarf2out changes
- Authentication-results: sourceware.org; auth=none
- References: <1406489825-9561-1-git-send-email-andi at firstfloor dot org> <1406489825-9561-2-git-send-email-andi at firstfloor dot org> <CAHACq4rQXWDQeAn17Ff3DcT=J+G8A+Poiop_nX-_KbVd7wYw8g at mail dot gmail dot com>
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);
>  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
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
Anyways I can drop the comment if you don't agree with it.