This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 does increase memory use for explosive cases like this (or rather
it stops us from discarding all the information we shouldn't have
discarded in the first place), but for all other testcases I was asked
to look into, it made no significant difference, as you probably
remember.

But then, if we want to generate better debug info, the first step is
to stop discarding the info we need for that.  This will *necessarily*
increase memory use.  You just can't possibly keep more information
around while using the same amount of memory.  Of course there are
more and less efficient ways to do it.

And it's not like you can blame my patch for the memory use.  Consider
that someone performs explicitly all the inlining that the compiler
performs for this one testcase, something that might as well be done
for generated code, as the argument against the patch went.  Oh, wait,
now they're all user variables, and memory use is still up to 2GB.
Now what can we do, if there isn't a debug info patch to blame any
more?

Oh, I know, let's apply that other patch that coalesces even user
variables, such that we can lower memory use down to 1GB!

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?  Surely there must be some other
pass that's generating an additional 1GB of memory in response to a
few hundred (or even thounsand) additional variables within a single
function, no?

Wouldn't we make users happier by lowering memory use for the
manually-inlined case as well, while keeping their code debuggable,
rather than scapegoating a patch that reverses an arbitrary and nearly
nonsensical decision made before, at a time when it appeared to make
some significant run-time performance difference that it no longer
does?

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]