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


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.

Yes, I do.


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.

Well, I see no reason we need to increase memory usage for the case '-g' is not specified. For better debug information (with -g!) I happily trade memory for better debugging.

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

Indeed. The current not-coalescing is bad, too.


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.

Richard.


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