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  8, 2007, "Daniel Berlin" <dberlin@dberlin.org> wrote:

> Just so we are straight here, o the ones who debug at -O2 -g are
> normal, but the people who make code like the testcase are  unusual.
> :)

If you still think debug information is something we emit to make the
use of GDB more bearable, let me welcome you to the 21st century.
People have been using debug information for all sorts of things.
Some examples:

- profiling.  Tell someone to compile their code with -O0 -g to enable
  them to profile and see what you get back

- monitoring.  Detect complex error conditions involving multiple
  processes running in the field using tools such as systemtap, frysk,
  (dtrace?), that rely on debug info to translate the conditions
  expressed in terms of functions, line numbers and user variables in
  the target program into multi-process and/or kernel-level
  conditional breakpoints.  Add error recovery through actuators on
  top of that for extra fun.  Suggest -O0 -g and see what you get back

- bug reporting and crash analysis.  Core files or equivalent can be
  useful if you can extract from it the information needed to debug
  the error that a customer experienced.  Whether the debug
  information is supplied to the customer to enable some bug reporting
  tool to generate a more useful report, or kept to the vendor for use
  in combination with the core file received from the customer, you
  need the debug info to match the binary shipped to the customer.
  Suggest -O0 -g and see what you get back

- various other kinds of binary analyses:
  https://ols2006.108.redhat.com/2007/Reprints/melo-Reprint.pdf has
  some examples

> And you'd reduce it's performance by a factor of 2, IIRC.
> Honestly, if your patch had increased memory consumption by say, 5%
> that would be one thing.
> This isn't even close.
> You've double it from 1 gigabyte to 2 gigabytes.
> That's just a "memory hit".

For the testcases I was given before, the memory his was negligible.
Is it just me or are you trying to overgeneralize the memory impact?

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