-g and -ggdb

-g and -ggdb

[Mark Mitchell]

Why doesn't -g generate DWARF2 output on Linux?  I'd think that -g
should be synonymous with -ggdb on systems (like Linux) where the
usual debugger is gdb, but this does not seem to be so.  The
documentation for -g produces debugging information in the operating
system's "native format".  Any thoughts?  I'd be happy to fix this, if
we have consensus on what to do.  My proposal:

  o Make the "native format" on Linux whatever -ggdb generates.

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: -g and -ggdb

[H.J. Lu]

> 
> 
> Why doesn't -g generate DWARF2 output on Linux?  I'd think that -g
> should be synonymous with -ggdb on systems (like Linux) where the
> usual debugger is gdb, but this does not seem to be so.  The
> documentation for -g produces debugging information in the operating
> system's "native format".  Any thoughts?  I'd be happy to fix this, if
> we have consensus on what to do.  My proposal:
> 
>   o Make the "native format" on Linux whatever -ggdb generates.
> 

Here is what is in gcc.info:

`-g'
     Produce debugging information in the operating system's native
     format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this
     debugging information.

`-ggdb'
     Produce debugging information for use by GDB.  This means to use
     the most expressive format available (DWARF 2, stabs, or the
     native format if neither of those are supported), including GDB
     extensions if at all possible.

On Linux, the "native format" is stabs. gcc seems to work according
to the manual.


-- 
H.J. Lu (hjl@gnu.org)

Re: -g and -ggdb

[Per Bothner]

> On Linux, the "native format" is stabs. gcc seems to work according
> to the manual.

The point is that the native on format on Linux *should* be Dwarf2,
as soon as Dwarf2 works as well or better than stabs.  The question
is:  Are we there yet?  I think we are close.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner

Re: -g and -ggdb

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    >> 
    >> 
    >> Why doesn't -g generate DWARF2 output on Linux?  I'd think that
    >> -g should be synonymous with -ggdb on systems (like Linux)
    >> where the usual debugger is gdb, but this does not seem to be
    >> so.  The documentation for -g produces debugging information in
    >> the operating system's "native format".  Any thoughts?  I'd be
    >> happy to fix this, if we have consensus on what to do.  My
    >> proposal:
    >> 
    >> o Make the "native format" on Linux whatever -ggdb generates.
    >> 

    H> Here is what is in gcc.info:

    H> `-g' Produce debugging information in the operating system's
    H> native format (stabs, COFF, XCOFF, or DWARF).  GDB can work
    H> with this debugging information.

    H> `-ggdb' Produce debugging information for use by GDB.  This
    H> means to use the most expressive format available (DWARF 2,
    H> stabs, or the native format if neither of those are supported),
    H> including GDB extensions if at all possible.

Thanks, I read that too.

    H> On Linux, the "native format" is stabs. gcc seems to work
    H> according to the manual.

I'm not sure what you mean by "native format".  On Solaris, for
instance, I would understand "native format" to mean the format used
in the system (vendor) compilation system; in particular, whatever
format is used by dbx.  I would expect -g to generate this kind of
debugging info.  And, I would expect -ggdb to use the most expressive
format, which might well be different.

However, on Linux, the "vendor" toolchain is GNU.  So, the usual
debugger is gdb.  So, the "native format" should be whatever works best
with gdb, IMO.  That's what -ggdb.  At present, on Linux, egcs -g
generates stabs, while -ggdb generates DWARF2.  

I claim that this situation makes no sense.  In particular, if GDB is
the usual debugger, then -g should be the same as -ggdb, so either -g
or -ggdb is currently doing the wrong thing.

But, perhaps I'm missing something: what do you mean that stabs are
the native format on Linux?  Is there a meaning of native other than
the one I'm thinking of? 

    H> -- H.J. Lu (hjl@gnu.org)

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Re: -g and -ggdb

[H.J. Lu]

> However, on Linux, the "vendor" toolchain is GNU.  So, the usual
> debugger is gdb.  So, the "native format" should be whatever works best
> with gdb, IMO.  That's what -ggdb.  At present, on Linux, egcs -g
> generates stabs, while -ggdb generates DWARF2.  
> 
> I claim that this situation makes no sense.  In particular, if GDB is
> the usual debugger, then -g should be the same as -ggdb, so either -g
> or -ggdb is currently doing the wrong thing.
> 
> But, perhaps I'm missing something: what do you mean that stabs are
> the native format on Linux?  Is there a meaning of native other than
> the one I'm thinking of? 

When we started working on ELF and gdb, DWARF2 was not an option since
gcc didn't support it as good as stabs. So we chose stabs as the native
format for Linux. I just saw a DWARF2 bug reported a few days ago.

-- 
H.J. Lu (hjl@gnu.org)

Re: -g and -ggdb

[Mark Mitchell]

>>>>> "H" == H J Lu <hjl@lucon.org> writes:

    >> However, on Linux, the "vendor" toolchain is GNU.  So, the
    >> usual debugger is gdb.  So, the "native format" should be
    >> whatever works best with gdb, IMO.  That's what -ggdb.  At
    >> present, on Linux, egcs -g generates stabs, while -ggdb
    >> generates DWARF2.
    >> 
    >> I claim that this situation makes no sense.  In particular, if
    >> GDB is the usual debugger, then -g should be the same as -ggdb,
    >> so either -g or -ggdb is currently doing the wrong thing.
    >> 
    >> But, perhaps I'm missing something: what do you mean that stabs
    >> are the native format on Linux?  Is there a meaning of native
    >> other than the one I'm thinking of?

    H> When we started working on ELF and gdb, DWARF2 was not an
    H> option since gcc didn't support it as good as stabs. So we
    H> chose stabs as the native format for Linux. I just saw a DWARF2
    H> bug reported a few days ago.

If DWARF2 support is truly busted, then -ggdb should generate stabs,
not DWARF2.  (If I really want DWARF2, I could always use -gdwarf-2.)

The point is simply that -g and -ggdb should be the same on Linux,
since GDB is the native debugger.  I propose that either we change
-ggdb to generate stabs, or -g to generate dwarf.  I was very
surprised to find that the two switches did different things.

    H> -- H.J. Lu (hjl@gnu.org)

-- 
Mark Mitchell		mmitchell@usa.net
Stanford University	http://www.stanford.edu

Debug formats on Linux

[Joseph S. Myers]

On Fri, 5 Dec 1997, Mark Mitchell wrote:

> Why doesn't -g generate DWARF2 output on Linux?  I'd think that -g
> should be synonymous with -ggdb on systems (like Linux) where the
> usual debugger is gdb, but this does not seem to be so.  The
> documentation for -g produces debugging information in the operating
> system's "native format".  Any thoughts?  I'd be happy to fix this, if
> we have consensus on what to do.  My proposal:
>
>   o Make the "native format" on Linux whatever -ggdb generates.

and on Sat, 6 Dec 1997, Per Bothner wrote:

> > On Linux, the "native format" is stabs. gcc seems to work according
> > to the manual.
>
> The point is that the native on format on Linux *should* be Dwarf2,
> as soon as Dwarf2 works as well or better than stabs.  The question
> is:  Are we there yet?  I think we are close.

Nearly three years on, we still have the same confusing situation that -g
generates stabs and -ggdb generates DWARF2 on Linux, even though gdb is
the native debugger.  Are we yet ready (in terms of maturity of DWARF2
support versus stabs in GCC and GDB, and in gdb sensibly handling
executables containing a mixture of both debugging types) for this to
change?  Is a move to DWARF2 still considered desirable if it is ready to
become the native Linux format?

It has also been mentioned, though I can't find the relevant messages
right now, that DWARF2 debugging info would allow debugging to work with
-fomit-frame-pointer on systems where it presently doesn't.  If this is
the case, and if GDB has or gets the support for this, that would seem a
reason to change (and -fomit-frame-pointer could then be turned on at -O
or -O2 for such systems if beneficial, e.g. x86-linux).

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Debug formats on Linux

[Mark Mitchell]

>>>>> "Joseph" == Joseph S Myers <jsm28@cam.ac.uk> writes:

    Joseph> Nearly three years on, we still have the same confusing
    Joseph> situation that -g generates stabs and -ggdb generates

Yes. 

I suspect that every new GCC platform will use DWARF2.  (I think that
IA64-Linux uses it.)

Why we can't switch on IA32-Linux is still somewhat beyond me, and I
still find the documentation as I did years ago.

I have largely given up fighting this fight, though.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: Debug formats on Linux

[Joseph S. Myers]

On Fri, 27 Oct 2000, Mark Mitchell wrote:

> I suspect that every new GCC platform will use DWARF2.  (I think that
> IA64-Linux uses it.)
>
> Why we can't switch on IA32-Linux is still somewhat beyond me, and I
> still find the documentation as I did years ago.

The following patch does the minimal conservative solution of making
the change on i?86-pc-linux-gnu only - it could probably be made in
the toplevel linux.h instead.

It isn't yet ready to commit, because of the following test
regressions on i686-pc-linux-gnu (though, it removes the two failures
for g++.ext/instantiate1.C):

FAIL: gcc.c-torture/unsorted/loop386.c,  -O3 -g
(ICE at dwarf2out.2:8366 (add_abstract_origin_attribute))

FAIL: g77.f-torture/compile/20000511-2.f,  -O3 -g
FAIL: g77.f-torture/compile/20000629-1.f,  -O3 -g
FAIL: g77.f-torture/compile/980310-3.f,  -O3 -g
FAIL: g77.f-torture/compile/980310-4.f,  -O3 -g
FAIL: g77.f-torture/compile/980310-7.f,  -O3 -g
FAIL: g77.f-torture/execute/19981119-0.f compilation,  -O3 -g
FAIL: g77.f-torture/execute/auto0.f compilation,  -O3 -g
FAIL: g77.f-torture/execute/auto1.f compilation,  -O3 -g
(all ICE at dwarf2out.c:8114 (add_bound_info))

These can be tested without the patch by compiling the individual
testcases with -gdwarf-2 -O3; perhaps someone understanding Fortran
and g77 could look at why those Fortran cases crash and whether the
problem is with the Fortran front end or in the DWARF2 support.
[NOTE: -gdwarf-2 not -gdwarf2, since -gdwarf2 is DWARF1, as discussed
long ago.]

(The change does increase executable sizes somewhat - by about 40% -
but of course this only affects unstripped executables compiled with
debugging.  Where the disk space is a problem a user can always use
-gstabs or -g1 and trade disk space against the reduced expressivity
of the debug information and possible difficulties debugging in the
presence of some optimisations.  In addition, -feliminate-dwarf2-dups
reduces the overhead to about 18%.)

Executable sizes before the patch (stabs debugging):

-rwxr-xr-x    1 root     root      7142838 Oct 27 23:45 cc1
-rwxr-xr-x    1 root     root      7336713 Oct 27 23:45 cc1obj
-rwxr-xr-x    1 root     root      9192466 Oct 27 23:45 cc1plus
-rwxr-xr-x    1 root     root      8396253 Oct 27 23:45 f771
-rwxr-xr-x    1 root     root      7681888 Oct 27 23:45 jc1

Executable sizes after the patch (DWARF2 debugging):

-rwxrwxr-x    1 jsm28    jsm28     9690242 Oct 28 01:09 cc1
-rwxrwxr-x    1 jsm28    jsm28     9885021 Oct 28 01:19 cc1obj
-rwxrwxr-x    1 jsm28    jsm28    12883234 Oct 28 01:13 cc1plus
-rwxrwxr-x    1 jsm28    jsm28    12549193 Oct 28 01:16 f771
-rwxrwxr-x    1 jsm28    jsm28    10504716 Oct 28 01:18 jc1

Executable sizes after the patch with -feliminate-dwarf2-dups:

-rwxrwxr-x    1 jsm28    jsm28     8365736 Oct 28 09:47 cc1
-rwxrwxr-x    1 jsm28    jsm28     8559876 Oct 28 09:57 cc1obj
-rwxrwxr-x    1 jsm28    jsm28    11157091 Oct 28 09:51 cc1plus
-rwxrwxr-x    1 jsm28    jsm28     9652617 Oct 28 09:54 f771
-rwxrwxr-x    1 jsm28    jsm28     9054916 Oct 28 09:56 jc1

2000-10-28  Joseph S. Myers  <jsm28@cam.ac.uk>

	* config/i386/linux.h (PREFERRED_DEBUGGING_TYPE): Define to
	DWARF2_DEBUG for glibc.

--- linux.h.orig	Mon Oct 23 21:55:57 2000
+++ linux.h	Sat Oct 28 00:10:39 2000
@@ -29,6 +29,12 @@
 #include <i386/att.h>	/* Use the i386 AT&T assembler syntax */
 #include <linux.h>	/* some common stuff */

+/* X86 Linux/glibc now uses DWARF2.  */
+#ifndef USE_GNULIBC_1
+#undef PREFERRED_DEBUGGING_TYPE
+#define PREFERRED_DEBUGGING_TYPE DWARF2_DEBUG
+#endif
+
 /* Output at beginning of assembler file.  */
 /* The .file command should always begin the output.  */
 #undef ASM_FILE_START

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: Debug formats on Linux

[Daniel Berlin]

"Joseph S. Myers" <jsm28@cam.ac.uk> writes:

> On Fri, 27 Oct 2000, Mark Mitchell wrote:
> 
> > I suspect that every new GCC platform will use DWARF2.  (I think that
> > IA64-Linux uses it.)
> >
> > Why we can't switch on IA32-Linux is still somewhat beyond me, and I
> > still find the documentation as I did years ago.
> 
> The following patch does the minimal conservative solution of making
> the change on i?86-pc-linux-gnu only - it could probably be made in
> the toplevel linux.h instead.
> 
> It isn't yet ready to commit, because of the following test
> regressions on i686-pc-linux-gnu (though, it removes the two failures
> for g++.ext/instantiate1.C):
> 
> FAIL: gcc.c-torture/unsorted/loop386.c,  -O3 -g
> (ICE at dwarf2out.2:8366 (add_abstract_origin_attribute))
> 
> FAIL: g77.f-torture/compile/20000511-2.f,  -O3 -g
> FAIL: g77.f-torture/compile/20000629-1.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-3.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-4.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-7.f,  -O3 -g
> FAIL: g77.f-torture/execute/19981119-0.f compilation,  -O3 -g
> FAIL: g77.f-torture/execute/auto0.f compilation,  -O3 -g
> FAIL: g77.f-torture/execute/auto1.f compilation,  -O3 -g
> (all ICE at dwarf2out.c:8114 (add_bound_info))
> 
> These can be tested without the patch by compiling the individual
> testcases with -gdwarf-2 -O3; perhaps someone understanding Fortran
> and g77 could look at why those Fortran cases crash and whether the
> problem is with the Fortran front end or in the DWARF2 support.
> [NOTE: -gdwarf-2 not -gdwarf2, since -gdwarf2 is DWARF1, as discussed
> long ago.]
> 
> (The change does increase executable sizes somewhat - by about 40% -
> but of course this only affects unstripped executables compiled with
> debugging.  Where the disk space is a problem a user can always use
> -gstabs or -g1 and trade disk space against the reduced expressivity
> of the debug information and possible difficulties debugging in the
> presence of some optimisations.  In addition, -feliminate-dwarf2-dups
> reduces the overhead to about 18%.)


Yeah, you really need to use C++ programs to see a much bigger gain
from eliminate-dwarf2-dups.

Also, if you look at the overhead, most of it is actually because of
the labels we use in eliminating the dups. 
If you do everything possible to cut down the number of labels in the
assembly file, you'll get much smaller dwarf2 files.

For a test, change dwarf2out.c to never emit labels for
inter-die-references (which of course, defeats the purpose, and makes
it useless, but this is just for test purposes), and watch how much
smaller your dwarf2 executables get.



--Dan

Re: Debug formats on Linux

[Toon Moene]

Joseph S. Myers wrote:

> FAIL: g77.f-torture/compile/20000511-2.f,  -O3 -g
> FAIL: g77.f-torture/compile/20000629-1.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-3.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-4.f,  -O3 -g
> FAIL: g77.f-torture/compile/980310-7.f,  -O3 -g
> FAIL: g77.f-torture/execute/19981119-0.f compilation,  -O3 -g
> FAIL: g77.f-torture/execute/auto0.f compilation,  -O3 -g
> FAIL: g77.f-torture/execute/auto1.f compilation,  -O3 -g
> (all ICE at dwarf2out.c:8114 (add_bound_info))

> These can be tested without the patch by compiling the individual
> testcases with -gdwarf-2 -O3; perhaps someone understanding Fortran
> and g77 could look at why those Fortran cases crash and whether the
> problem is with the Fortran front end or in the DWARF2 support.

The Fortran failures are due to the fact that add_bound_info (in
dwarf2out.c) doesn't handle INDIRECT_REF as a bound tree code.  I do not
know enough about this to decide whether this use of INDIRECT_REF is
correct or not.  If it is harmless, we could start by adding it to the
list of codes emitted by Ada, and ignored by dwarf2out.c:

    case MAX_EXPR:
    case VAR_DECL:
    case COMPONENT_REF:
    case COND_EXPR:
      /* ??? These types of bounds can be created by the Ada front end,
         and it isn't clear how to emit debug info for them.  */
      break;

Cheers,

-- 
Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
GNU Fortran 95: http://g95.sourceforge.net/ (under construction)

Re: Debug formats on Linux

[jfm2]

> 
> On Fri, 5 Dec 1997, Mark Mitchell wrote:
> 
> > Why doesn't -g generate DWARF2 output on Linux?  I'd think that -g
> > should be synonymous with -ggdb on systems (like Linux) where the
> > usual debugger is gdb, but this does not seem to be so.  The
> > documentation for -g produces debugging information in the operating
> > system's "native format".  Any thoughts?  I'd be happy to fix this, if
> > we have consensus on what to do.  My proposal:
> >
> >   o Make the "native format" on Linux whatever -ggdb generates.
> 
> and on Sat, 6 Dec 1997, Per Bothner wrote:
> 
> > > On Linux, the "native format" is stabs. gcc seems to work according
> > > to the manual.
> >
> > The point is that the native on format on Linux *should* be Dwarf2,
> > as soon as Dwarf2 works as well or better than stabs.  The question
> > is:  Are we there yet?  I think we are close.
> 
> Nearly three years on, we still have the same confusing situation that -g
> generates stabs and -ggdb generates DWARF2 on Linux, even though gdb is
> the native debugger.  Are we yet ready (in terms of maturity of DWARF2
> support versus stabs in GCC and GDB, and in gdb sensibly handling
> executables containing a mixture of both debugging types) for this to
> change?  Is a move to DWARF2 still considered desirable if it is ready to
> become the native Linux format?
> 
> It has also been mentioned, though I can't find the relevant messages
> right now, that DWARF2 debugging info would allow debugging to work with
> -fomit-frame-pointer on systems where it presently doesn't.  If this is
> the case, and if GDB has or gets the support for this, that would seem a
> reason to change (and -fomit-frame-pointer could then be turned on at -O
> or -O2 for such systems if beneficial, e.g. x86-linux).
> 

I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
well under 10%, and I think under 5%.  I found this funny since I
would expect an additional register woukld have a big impact on
register-starved x86s.  But unless omit-frame-pointer gives a far
bigger impact I would not want to go through yet another massive
change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
the uncompatible C++ libraries from
 gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

Re: Debug formats on Linux

[Michael Meissner]

On Sat, Oct 28, 2000 at 02:13:45AM +0200, jfm2@club-internet.fr wrote:
> I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
> well under 10%, and I think under 5%.  I found this funny since I
> would expect an additional register woukld have a big impact on
> register-starved x86s.  But unless omit-frame-pointer gives a far
> bigger impact I would not want to go through yet another massive
> change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
> the uncompatible C++ libraries from
>  gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3

To some extent, it depends on the processor (386, 486, pentium, etc.).  Unlike
other (saner) architectures, the x86 instruction family uses a different
address format to address things via the stack register compared to the frame
pointer register.  This address format uses larger instructions, which reduces
the efficiency of the i-cache slightly.  I believe in the older processors also
executed these instructions slower due to having to use a prefix as part of the
instruction (I haven't looked in detail what the current Pentium-III and AMD
processors do with these instructions).

-- 
Michael Meissner, Red Hat, Inc.
PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA
Work:	  meissner@redhat.com		phone: +1 978-486-9304
Non-work: meissner@spectacle-pond.org	fax:   +1 978-692-4482

Re: Debug formats on Linux

[jfm2]

> 
> On Sat, Oct 28, 2000 at 02:13:45AM +0200, jfm2@club-internet.fr wrote:
> > I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
> > well under 10%, and I think under 5%.  I found this funny since I
> > would expect an additional register woukld have a big impact on
> > register-starved x86s.  But unless omit-frame-pointer gives a far
> > bigger impact I would not want to go through yet another massive
> > change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
> > the uncompatible C++ libraries from
> >  gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3
> 
> To some extent, it depends on the processor (386, 486, pentium, etc.).  Unlike
> other (saner) architectures, the x86 instruction family uses a different
> address format to address things via the stack register compared to the frame
> pointer register.  This address format uses larger instructions, which reduces
> the efficiency of the i-cache slightly.  I believe in the older processors also
> executed these instructions slower due to having to use a prefix as part of the
> instruction (I haven't looked in detail what the current Pentium-III and AMD
> processors do with these instructions).
> 

I tried with a PII/400.  I used alternatiely cpu=i386, cpu=i686 and
arch=i686.  omit-frame-pointer never made a big difference (ie > 10%),
ever was far smaller than 10%.

Fropm distant memories on the 386 use of (E)BP is not as flexible than
other registers like eax so it is perhaps difficult to use it as an
additional general register.  I don't know if is still true when you
allow use of PPro instructions

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

Re: Debug formats on Linux

[Richard Zidlicky]

On Sat, Oct 28, 2000 at 02:13:45AM +0200, jfm2@club-internet.fr wrote:

> I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
> well under 10%, and I think under 5%.  I found this funny since I
> would expect an additional register woukld have a big impact on
> register-starved x86s.  But unless omit-frame-pointer gives a far
> bigger impact I would not want to go through yet another massive
> change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
> the uncompatible C++ libraries from
>  gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3

fomit-frame-pointer gives better results to me, almost always around 
10%, notably with programs that are hard to speed up otherwise. That 
is for x86 and m68k, 2.7.2.3, 2.8.[01], 2.95.*.

Bye
Richard

Re: Debug formats on Linux

[jfm2]

> On Sat, Oct 28, 2000 at 02:13:45AM +0200, jfm2@club-internet.fr wrote:
> 
> > I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
> > well under 10%, and I think under 5%.  I found this funny since I
> > would expect an additional register woukld have a big impact on
> > register-starved x86s.  But unless omit-frame-pointer gives a far
> > bigger impact I would not want to go through yet another massive
> > change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
> > the uncompatible C++ libraries from
> >  gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3
> 
> fomit-frame-pointer gives better results to me, almost always around 
> 10%, notably with programs that are hard to speed up otherwise. That 
> is for x86 and m68k, 2.7.2.3, 2.8.[01], 2.95.*.
> 

What were the other parms?  My method was: start from "-O2)
-mcpu=pentiumpro" (later I redid it with "-O2 -march=pentiumpro" and
then successively apply every parm and look for the one giving the
bigger increase (inline-functions) and take the new flag set
(equivalent to -03 -mcpu=i686) as a new starting point.  The fact I
was optimizing for the P6 core instead of plain 386 and the fact I was
at O3 optimization level can have an influence.  I have noticed some
strange synergies during my tests: some parms have little or no effect
if some other parm is not present, in other occasions a parm who used
to have a positive effect has anegative effect if some other is
active.

This could explain the differences between our results.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

Re: Debug formats on Linux

[jfm2]

> 
> On Thu, Nov 02, 2000 at 10:29:49PM +0100, jfm2@club-internet.fr wrote:
> > 
> > > On Sat, Oct 28, 2000 at 02:13:45AM +0200, jfm2@club-internet.fr wrote:
> > > 
> > > > I benchmarked -fomit-frame-pointer with gcc 2.95 and speed bonus was
> > > > well under 10%, and I think under 5%.  I found this funny since I
> > > > would expect an additional register woukld have a big impact on
> > > > register-starved x86s.  But unless omit-frame-pointer gives a far
> > > > bigger impact I would not want to go through yet another massive
> > > > change on Linux.  I have had enough with libc4 -> libc5 -> glibc plus
> > > > the uncompatible C++ libraries from
> > > >  gcc-2.7 -> egcs -> gcc-2.9[56]->gcc-3
> > > 
> > > fomit-frame-pointer gives better results to me, almost always around 
> > > 10%, notably with programs that are hard to speed up otherwise. That 
> > > is for x86 and m68k, 2.7.2.3, 2.8.[01], 2.95.*.
> > > 
> > 
> > What were the other parms?  My method was: start from "-O2)
> > -mcpu=pentiumpro" (later I redid it with "-O2 -march=pentiumpro" and
> > then successively apply every parm and look for the one giving the
> > bigger increase (inline-functions) and take the new flag set
> > (equivalent to -03 -mcpu=i686) as a new starting point.  The fact I
> > was optimizing for the P6 core instead of plain 386 and the fact I was
> > at O3 optimization level can have an influence.  I have noticed some
> > strange synergies during my tests: some parms have little or no effect
> > if some other parm is not present, in other occasions a parm who used
> > to have a positive effect has anegative effect if some other is
> > active.
> > 
> > This could explain the differences between our results.
> 
> The differences can be probably explained with function sizes etc.
> It is a m68k emulator and inlining everything hurts cahces so there
> are some quite small functions.
> Also I have used all other tricks like inline assembly, using register
> parameters for some functions and always optimise for the exact chip.
> 
> Bye
> Richard
> 
> 


According to doc -finline-function does not inline everything only
small functions.  But I agree about -O3 being a double edged sword
duie to code size increase.

I was using the byte benchamrk.  I also noticed thazt on some tests
cpu=pentiumpro was faster than arch=pentiumpro, and on the FP
emulation test cpu=i386 beats cpu=i686 or arch=i686 by around 20%.
This suggests that there is something wrong with the 2.95 optimizer.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

Re: Debug formats on Linux

[Richard Zidlicky]

On Fri, Nov 03, 2000 at 08:50:56AM +0100, jfm2@club-internet.fr wrote:

[..snip..]

> 
> According to doc -finline-function does not inline everything only
> small functions.  But I agree about -O3 being a double edged sword
> duie to code size increase.

sure, I never use -O3 for my own programs - it is much better to use
the inline keyword where apropriate and -funroll-loops where it helps.

> I was using the byte benchamrk.  I also noticed thazt on some tests
> cpu=pentiumpro was faster than arch=pentiumpro, and on the FP
> emulation test cpu=i386 beats cpu=i686 or arch=i686 by around 20%.
> This suggests that there is something wrong with the 2.95 optimizer.

benchmarks aren't good for my purposes, they test the optimizer on 
"average" code. Very often the most performance critical code will 
be already programmed for speed so it has little common with average
code.
Mostly I found march=chip produce faster but often bigger code.


Bye
Richard

Re: Debug formats on Linux

[jfm2]

> 
> On Fri, Nov 03, 2000 at 08:50:56AM +0100, jfm2@club-internet.fr wrote:
> 
> [..snip..]
> 
> > 
> > According to doc -finline-function does not inline everything only
> > small functions.  But I agree about -O3 being a double edged sword
> > duie to code size increase.
> 
> sure, I never use -O3 for my own programs - it is much better to use
> the inline keyword where apropriate and -funroll-loops where it helps.
> 
> > I was using the byte benchamrk.  I also noticed thazt on some tests
> > cpu=pentiumpro was faster than arch=pentiumpro, and on the FP
> > emulation test cpu=i386 beats cpu=i686 or arch=i686 by around 20%.
> > This suggests that there is something wrong with the 2.95 optimizer.
> 
> benchmarks aren't good for my purposes, they test the optimizer on 
> "average" code. Very often the most performance critical code will 
> be already programmed for speed so it has little common with average
> code.

The byte benchmark is supposed to be not an artificial benchmark but
one made of problems who are frequently found in practice like
decomposition in Fourier series.  Problem is that world is not as
simple that in the good old times of 386.  In those days you could
take results of a benchmerk exerting instruction A and of benchmark
exerting instruction B and deduce results on progrem mixing A and B
instructions.  This is no longer true.

As an example consider the plain Pentium with its two asymetric
integer pipelines only one them being able to excute complex
instructions like multiplications.  It could happen that for comparing
two compilers you run a benchmark and find they get identical results
on both the test exerting simple instructions and on the test exerting
multiplication and division.  However once you compile normal code who
mixes simple and complex instructions you could find that compiler A
is not smart enough to account for the asymetric nature of the Pentium
so in many occasions a multiplication will be waiting because an
addition is using the U (universal) pipeline while the V one (unusable
for multiplication) is empty.  Thus if compiler B is smart enough to
manage that multiplications will ever find a V pipeline busy with
simple instructions and an empty U pipeline then code generated by B
will be much faster than code generated by A on mixed instruction (ie
typical) programs despite the fact they are equivalent on code
exerting a single type of instructions

This illustrates how necessary it is to understand the limits of a
benchmark when analyzing its results

> Mostly I found march=chip produce faster but often bigger code.
> 

But unless you know your code will run on only one computer you rarely
can use -arch.  For instance the K6 family will not accept code
compiled with -arch=i686 and fast K6/2s beat the pants of equally
priced PIIs in integer-intensive code so you cannot discard as
obsolete those processors accepting only the P5 instuction set.  And
I can tell you (I have one) a K6/2 is significantly faster on code
compiled with -mcpu=i686 than on code compiled with -march=i586.
Compiler was gcc 2.95.2

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org