Re: comparing die trees/graphs

[Mark Wielaard <mjw at redhat dot com>]

On Mon, 2010-07-19 at 17:55 -0700, Roland McGrath wrote:
> > OK, so some of the equivalence detection can be done when we read in the
> > original DIEs and others when we write out the DIEs again.
> 
> I don't really follow this comment at all.  

That is probably because I assumed something worked in a certain way
based on the name, and I didn't yet grok the code.

> The mandate for dwarfcmp is to handle any valid physical formulation of
> each input and say correctly whether they are semantically equivalent,
> and there is no writing out involved at all there.
>
> The existing design for dwarf_output has two phases: copy construction,
> which is what drives all the reading and creation of internal memory
> representations of CUs; and output, where format writing is done.
> All of the duplicate detection is part of the first phase.

OK thanks, that was my misunderstanding then.

BTW. I do think it is good to be explicit about the classes of
equivalence we can/want/do detect. It is sometimes very easy for us
humans to say "look semantically equivalent", while the (syntactical)
comparisons needed to proof such equivalence are pretty involved. And it
would allow us to more easily experiment with turning some of them off.
Like we have for context equivalence (equal-enough).

> We haven't really talked about that whole design yet to establish a
> shared vocabulary, so picking apart your remark this way is probably
> premature.  But, I really don't know what you meant.

No, please do pick them apart. It probably shows sloppy thinking/bad
interpretation of the code if I say things which don't are rooted in any
logical universe :)

I was just thinking about how/when detecting what kinds of equivalence
is the most opportune. My thinking was that some comparisons are
easier/cheaper done when we are already doing some transformation on
(reading in/writing out) the whole DIE tree already.

Cheers,

Mark