On Jun 18, 2009, Diego Novillo <dnovi...@google.com> wrote: > 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). There had been too much debug-info-related patching after the previous merge on both sides, and tracking them all down would have been a pain. So I ran another merge. > painful in one dimension or another. Hopefully this will be easier to > deal with than the current -O2 -g disaster. +1 >> 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. Heh, I asked *when*, not *where*! Doh. Sorry, I hope it wasn't too confusing. >> 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. +1 That was a factor I took very much into consideration in the design. I'm happy this is becoming clearer now that the smoke is vanishing ;-) -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer