This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Variable tracking (location lists support) - part 1
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: Vladimir Makarov <vmakarov at redhat dot com>
- Cc: law at redhat dot com, "Joseph S. Myers" <jsm at polyomino dot org dot uk>,Josef Zlomek <zlomj9am at artax dot karlin dot mff dot cuni dot cz>,gcc-patches at gcc dot gnu dot org
- Date: Fri, 30 Jan 2004 11:38:03 +0100
- Subject: Re: Variable tracking (location lists support) - part 1
- References: <200401292010.i0TKA7rI008229@speedy.slc.redhat.com> <401975C9.90508@redhat.com>
> 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
>
> >
> >
>