Re: Debug formats on Linux

Re: Debug formats on Linux

[mrs]

> Date: Sun, 29 Oct 2000 13:36:18 +0100
> From: Toon Moene <toon@moene.indiv.nluug.nl>
> To: "Joseph S. Myers" <jsm28@cam.ac.uk>
> CC: Mark Mitchell <mark@codesourcery.com>, gcc@gcc.gnu.org

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

Please try the below patch, and if it makes things work better...
we can try and get it in.

Doing diffs in dwarf2out.c.~1~:
*** dwarf2out.c.~1~	Mon Oct 30 11:16:19 2000
--- dwarf2out.c	Mon Oct 30 11:17:23 2000
*************** add_bound_info (subrange_die, bound_attr
*** 8106,8111 ****
--- 8106,8112 ----
      case VAR_DECL:
      case COMPONENT_REF:
      case COND_EXPR:
+     case INDIRECT_REF:
        /* ??? 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;
--------------

Re: Debug formats on Linux

[Joseph S. Myers]

On Mon, 30 Oct 2000 mrs@wrs.com wrote:

> Please try the below patch, and if it makes things work better...
> we can try and get it in.
>
> Doing diffs in dwarf2out.c.~1~:
> *** dwarf2out.c.~1~	Mon Oct 30 11:16:19 2000
> --- dwarf2out.c	Mon Oct 30 11:17:23 2000
> *************** add_bound_info (subrange_die, bound_attr
> *** 8106,8111 ****
> --- 8106,8112 ----
>       case VAR_DECL:
>       case COMPONENT_REF:
>       case COND_EXPR:
> +     case INDIRECT_REF:
>         /* ??? 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;
> --------------

With this patch (plus my patch to turn DWARF2 on by default on
i?86-pc-linux-gnu), the only regressions I now get are

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

FAIL: g77.f-torture/execute/19981119-0.f compilation,  -O3 -g
UNTESTED: g77.f-torture/execute/19981119-0.f execution,  -O3 -g
(ICE in add_bound_info, at dwarf2out.c:8115)

which are balanced by the two tests which using DWARF2 makes pass
(g++.ext/instantiate1.C lines 18 and 20).

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

Re: Debug formats on Linux

[Robert Dewar]

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

Our experience with Ada, where the extensive use of pragma Inline is
encouraged and expected, is that -O3 often increases execution time,
or increases space with no appreciable time gain, so we recommend
against its use.

Re: Debug formats on Linux

[Tim Prince]

As g77 has no inlining facility other than -O3, that option has to be used
with careful selection
of which subroutines are gathered together in files in which order.  Recent
snapshots have
overcome to a great extent the long standing problem about -O2  being
usually slower than -Os
on x86, apparently at the expense of bringing back more bugs.  Yes, the -m
options which are
supported in gcc are even more effective than with major commercial
compilers.
----- Original Message -----
From: "Robert Dewar" <dewar@gnat.com>
To: <Richard.Zidlicky@stud.informatik.uni-erlangen.de>;
<jfm2@club-internet.fr>
Cc: <gcc@gcc.gnu.org>
Sent: Sunday, November 05, 2000 4:27 AM
Subject: Re: Debug formats on Linux


> <<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.
> >>
>
> Our experience with Ada, where the extensive use of pragma Inline is
> encouraged and expected, is that -O3 often increases execution time,
> or increases space with no appreciable time gain, so we recommend
> against its use.

Re: Debug formats on Linux

[Robert Dewar]

<<No, they have a lot of duplicate info, and there are still
optimizations we don't pull off that we should (like factoring
location lists and putting them in .debug_loc, factoring strings and
putting them in .debug_str.)
BTW, this is what -feliminate-dwarf2-dups does, is eliminate the duplicates
Of course we still get killed by the overhead of so many labels.
Once we have a linker we can actually eliminate dwarf2 in, dwarf2 will
be as small as stabs, if not smaller.

It certainly has the capability to me much smaller than stabs.
>>

Ah OK! Your definition of "proper" was pretty extensive :-)

Yes, indeed if all duplication is removed, things should be much better.
It is not so easy to remove the duplicate information in the linker. Dwarf 2
was not exactly designed to facilitate this, but it certainlyis a major need.

Re: Debug formats on Linux

[Daniel Berlin]

dewar@gnat.com (Robert Dewar) writes:

> <<No, they have a lot of duplicate info, and there are still
> optimizations we don't pull off that we should (like factoring
> location lists and putting them in .debug_loc, factoring strings and
> putting them in .debug_str.)
> BTW, this is what -feliminate-dwarf2-dups does, is eliminate the duplicates
> Of course we still get killed by the overhead of so many labels.
> Once we have a linker we can actually eliminate dwarf2 in, dwarf2 will
> be as small as stabs, if not smaller.
> 
> It certainly has the capability to me much smaller than stabs.
> >>
> 
> Ah OK! Your definition of "proper" was pretty extensive :-)
> 
Yeah, i probably phraswed it wrong, it was late.

> Yes, indeed if all duplication is removed, things should be much better.
> It is not so easy to remove the duplicate information in the linker. Dwarf 2
> was not exactly designed to facilitate this, but it certainlyis a major need.
I know it's not, I tried for 3 weeks before i did it in the compiler.
The current linker just doesn't give us the information necessary to
do it.

I actually had a post-linker program that used libdwarf to eliminate
duplicates, but libdwarf's producer interface is too weak to make it
work well (it expects to produce one CU, and to produce it for an
object file).
--Dan

Re: Debug formats on Linux

[Robert Dewar]

<<Actually, this isn't true at all.
Proper DWARF2 is much smaller than stabs.
>>

That's really interesting, it is not what we have seen at all from any
of the DWARF2 gcc ports we have worked with, we have seen absolutely
HUGE increases in executable size. Perhaps these do not generate "proper"
DWARF2 :-)

Re: Debug formats on Linux

[Daniel Berlin]

dewar@gnat.com (Robert Dewar) writes:

> <<Actually, this isn't true at all.
> Proper DWARF2 is much smaller than stabs.
> >>
> 
> That's really interesting, it is not what we have seen at all from any
> of the DWARF2 gcc ports we have worked with, we have seen absolutely
> HUGE increases in executable size. Perhaps these do not generate "proper"
> DWARF2 :-)

No, they have a lot of duplicate info, and there are still
optimizations we don't pull off that we should (like factoring
location lists and putting them in .debug_loc, factoring strings and
putting them in .debug_str.)
BTW, this is what -feliminate-dwarf2-dups does, is eliminate the duplicates
Of course we still get killed by the overhead of so many labels.
Once we have a linker we can actually eliminate dwarf2 in, dwarf2 will
be as small as stabs, if not smaller.

It certainly has the capability to me much smaller than stabs.
--Dan

Re: Debug formats on Linux

[Robert Dewar]

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

One would hope that Stabs will still be usable on most platforms, since
this representation is so much more space efficient than DWARF2. 

Re: Debug formats on Linux

[Daniel Berlin]

dewar@gnat.com (Robert Dewar) writes:

> <<> I suspect that every new GCC platform will use DWARF2.  (I think that
> > IA64-Linux uses it.)
> >>
> 
> One would hope that Stabs will still be usable on most platforms, since
> this representation is so much more space efficient than DWARF2. 

Actually, this isn't true at all.
Proper DWARF2 is much smaller than stabs.
--Dan

Re: Debug formats on Linux

[Jeffrey A Law]

  In message < 20001028111319.6209534D81@nile.gnat.com >you write:
  > <<> I suspect that every new GCC platform will use DWARF2.  (I think that
  > > IA64-Linux uses it.)
  > >>
  > 
  > One would hope that Stabs will still be usable on most platforms, since
  > this representation is so much more space efficient than DWARF2. 
That's not necessarily true.

For example on PA64 dwarf2 is more compact than stabs would be for
most applications.  There are of course exceptions.

jeff

Re: Debug formats on Linux

[John Wehle]

> 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 look at the issue during late 1998 and was told that GDB didn't
currently support using DWARF2 for this.  I contributed GDB patches
to support debugging x86 functions where the frame pointer had been
eliminated which worked by parsing the prologue in January of 1999.
Unfortunately the patches never really got reviewed due to the GDB
people being busy with other things.  I was told in March of 2000
(which was the last time I checked on its status) that a more powerful
approach was in the works.

-- John
-------------------------------------------------------------------------
|   Feith Systems  |   Voice: 1-215-646-8000  |  Email: john@feith.com  |
|    John Wehle    |     Fax: 1-215-540-5495  |                         |
-------------------------------------------------------------------------

-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

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