Re: PR 23551: why should we coalesce inlined variables?

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  8, 2007, "Andrew Pinski" <pinskia@gmail.com> wrote:

> On 7/8/07, Alexandre Oliva <aoliva@redhat.com> wrote:
>> > Richard writes:
>> >> I propose to revert this patch for now.
>> 
>> >       I agree.  I think the patch should be reverted as the benefit does
>> > not justify the cost.
>> 
>> If we want to privilege memory use over debug information, I guess
>> this patch is the way to go.  Any privileging of non-inlined-function
>> variables over inlined-function variables is arbitrary, since
>> decisions on what to inline are mostly arbitrary nowadays, and they
>> change from one compiler release to another, and even between targets.

> Why do you think they are arbitrary?

Sorry if that came off as insulting or diminishing all the work that
goes into tuning the heuristics.  Not intended.  I can see that
"arbitrary" was a poor choice of wording, and I apologize for that.

Something I had in mind when I wrote that was word I got from one
heavy user of debug info, complaining about arbitrary decisions such
as inlining of static functions, which (not so) recent versions of GCC
started doing by default at -O2.  As a consequence of our decisions to
regard inlined variables as second-class citizens and other poor debug
info generation, their tools stopped working for optimized code.
Major regression, out of a simple yet "arbitrary" decision.  And it's
not that the decision per se is wrong, it's just that the debug info
generation wasn't improved to compensate for it, so there was a
theoretical performance boost, but the end result was an unusable
binary.

> I have not seen that many people complain about us getting worse
> debugging info for optimizated builds between releases.

I suppose you're talking about our bugzilla database.  I guess most of
the users who complain about this stuff are still heavy commercial
users who complain about them to their vendors, rather than to the
upstream project, since that's one of the things they pay the vendors
to do for them.  And that's what brings me here in this case ;-)

I'd be very surprised if I'm the only one in touch with heavy users of
GCC debug info beyond debuggers.

> Note any patch in this area should get a testcase or two to show where
> it can help in either debugging or optimization.

I think this will make sense once we get to a point in which patches
can begin to make any difference.  At this point, we drop useful
information at so many different spots that the hope that any simple
patch will trigger a positive outcome in terms of debug info is nil.
A lot of effort seems to have gone into disregarding debug info :-(

-- 
Alexandre Oliva         http://www.lsd.ic.unicamp.br/~oliva/
FSF Latin America Board Member         http://www.fsfla.org/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}