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.