On Mon, Jun 8, 2009 at 17:03, Alexandre Oliva<aol...@redhat.com> wrote:

> For the measurements, I won't use the last merge, but rather the trunk

Comparing trunk as of the last merge point is the easiest thing to do
(just checkout trunk at the revision that you last merged with the
branch).  That's why I suggested that.  Additionally, it gives you a
clear picture of how the branch differs from mainline without any
other artifacts.

Of course, if you've recently merged, then it shouldn't make much difference.


> What needs to be taken care of is something else: avoiding codegen
> differences.  This means that whatever factors you use to make decisions
> on whether or not to make a transformation shouldn't take debug
> annotations into account.  E.g., if you count how many references there
> are to a certain DEF, don't take the debug USEs into account.  If you
> count how many STMTs there are in a function or block to decide whether
> to inline it or duplicate it, don't count the annotations.

This is going to be a source of headaches.  But I don't think we'll
ever really win this fight.  Dealing with debug information will
painful in one dimension or another.  Hopefully this will be easier to
deal with than the current -O2 -g disaster.


> When in the documentation do you suggest this should go?

A new chapter in gccint.texi should be fine, I think.  It doesn't have
to start long, but we may add to it as time goes on.

> That said, the additional
> work would be explicitly optional, and certainly not necessarily taken
> up by the maintainer of the pass, but rather by someone interested in
> debug information.

I like it.  This is a good property.  In general, folks interested in
optimization are reluctant to care about debugging too much.  If we
can cater to both camps, we all win.


Diego.

Reply via email to