This is the mail archive of the gcc@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: Faster compilation speed


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


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