This is the mail archive of the
mailing list for the GCC project.
Re: Faster compilation speed
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Robert Dewar <dewar at gnat dot com>
- Cc: dje at watson dot ibm dot com, <shebs at apple dot com>, <gcc at gcc dot gnu dot org>,<mrs at apple dot com>
- Date: Fri, 9 Aug 2002 23:24:38 -0400 (EDT)
- Subject: Re: Faster compilation speed
- Reply-to: dberlin at dberlin dot org
On Fri, 9 Aug 2002, Robert Dewar wrote:
> << Saying "do not run any optimization at -O0" shows a tremendous
> lack of understanding or investigation. One wants minimal optimization
> even at -O0 to decrease the size of the IL representation of the function
> being compiled. The little bit of computation to perform trivial
> optimization more than makes up for itself with the decreased size of the
> IL that needs to be processed to generate the output.
> There are two reasons to run at -O0
> a) make the code as easy to debug as possible
> b) speedy compilation
> There is also a third reason that is relevant to safety critical code
> c) avoid optimization, on the grounds that it inteferes with verification
> Now with respect to a), the trouble with GCC is that the code generated
> with no optimization is really horrible. Much worse than typical competing
> compilers operating in no optimization mode. Now of course we can say
> "yes, but gcc is really doing what you want, the other compiler is not"
> but the fact remains that you are stuck between two unpleasant choices
> -O0 generates far too much code and giant executables
> -O1 already loses debugging information
> I think there is a real need for a mode which would do all possible
> optimizations that do NOT intefere with debugging. I would probably
> use this as my default development mode all the time.
Um, a *lot* of our O1 optimizations would not interefere with debugging in
a substantial manner if the stuff necessary to do var-tracking (and thus,
location lists) gets accepted. This is the register attribute stuff.
This stuff is done (mostly, there was one or two places in dwarf2out i
think i might need to copy and paste some code).
Try the cfg-branch, and it'll generate location lists to track variables
as they move through registers. It's on by default for -O2 or above.
Of course, gdb won't consume location lists (hopefully location
expressions soon), but that's another matter.
readelf will happily list the location lists.
Heck, in fact, you actually get better debugging because it currently does
it at an insn level, rather than a source line level, so variables should
still be described properly even if you step by instructions.
Though once i can move loclists over to the mainline, this will probably
move to a "-g4" level of debugging, and -g will only output the info
necessary to track variable location changes over source lines.