Variable tracking (location lists support) - part 1

[Jan Hubicka]

> law@redhat.com wrote:
> 
> >In message <Pine.LNX.4.58.0401291957130.23288@digraph.polyomino.org.uk>, 
> >"Josep
> >h S. Myers" writes:
> >>On Thu, 29 Jan 2004, Josef Zlomek wrote:
> >>
> >>> Without location lists, GDB printed some wierd values when debugging
> >>> optimized code.  GDB with support of location lists (GDB 6.0.1 and 
> >newer)
> >>> shows correct values of variables even when debugging optimized code
> >>> even with -fomit-frame-pointer (when !frame_pointer_needed a special 
> >locati
> >>on
> >>> list for describing the changes of stack pointer is emitted).
> >>
> >>Does this mean that some targets that didn't previously should now have
> >>-fomit-frame-pointer enabled at -O?  (The documentation saying
> >>"@option{-O} also turns on @option{-fomit-frame-pointer} on machines where
> >>doing so does not interfere with debugging.".)
> >That would be a significant step forward -- being able to turn on FP
> >elimination for ia32 is probably the easiest way to get a measureable
> >performance improvement I can think of :-)
> > 
> >
> 
> >Yes, that is true.  As I remember the improvement was 1.5-2% for pentium4 
> >on SPECINT2000.
It was 3.26% in my tests on K8 hardware (see my GCC summit paper).
It also cause 0.96% code size increase, but I think we can get around it
if we add some logic to fallback to frame pointer if there are very many
stack frame references.   But it is not ciritcal.

I was however under impression that all one need is the DWARF2 unwind
support to get this working, like we do on x86-64 where we elliminate
frame pointers by default.
This would mean defualting to -fomit-frame-pointer
-fasymchronous-unwind-tables.  I would definitly love this to happen.

Honza
> > 
> >
> Vlad
> 
> > 
> >
>