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

[Alexandre Oliva <aoliva at redhat dot com>]

On Jul  9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:

> On 7/9/07, Alexandre Oliva <aoliva@redhat.com> wrote:
>> On Jul  9, 2007, "Richard Guenther" <richard.guenther@gmail.com> wrote:
>> 
>> > So improve the way we are collecting information to produce debug info,
>> > but not disable optimizations.
>> 
>> +1
>> 
>> The patch I proposed has already been shown to not disable
>> optimizations, so I don't see what you're arguing for.

> It disables variable coalescing which is an optimization.

Make that "transformation".  It was shown to decrease overall
performance on few-register arches, and to do so even on many-register
arches for some specific testcases.

> Well, I see no reason we need to increase memory usage for the case
> '-g' is not specified.

Because GCC is by design a compiler that generates the very same code
regardless of -g.  We can't refrain from making certain
transformations depending on -g, because they might change the
generated code.  The mere presence of line number notes or other
annotations has been shown to have effects on certain other
transformations.  For example, the presence of trees holding location
information could affect decisions about inlining or loop unrolling,
and the presence of line number notes in RTL did cause some
differences in code with or without -g in the past.

>> Or should we instead take a more constructive approach and try to find
>> out why memory use exploded because of an increase in the number of
>> user variables inside a function?

> No, we instead should take a more constructive approach and fix the
> problem the right way.  Which is the part of my message you chose to
> not reply to.

The only reason I didn't respond to that portion of your e-mail was
because I'd just responded to similar claims in other e-mails I'd just
posted.

But then, what is "the right way"?  If adding a few thousand variables
to a function causes memory use to explode from 1GB to 2GB, and we
manage to avoid that with some variable coalescing, should we take
that as "problem solved" and hope nobody ever comes up with a case in
which coalescing does *not* address it?  Or should we try to find out
what is taking up all this memory, and try to improve *that*, such
that we no longer depend on coalescing to reduce memory use in this
and other cases?

-- 
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}