Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Tue, Sep 10, 2002 at 09:41:56PM -0700, David O'Brien wrote:
+. if ${CPUTYPE} == athlon-mp || ${CPUTYPE} == athlon-xp || ${CPUTYPE} ==
athlon-4 || ${CPUTYPE} == athlon
+_CPUCFLAGS = -march=${CPUTYPE}
. elif ${CPUTYPE} == k6-3
_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
Why stop there? Nearly all of the CPUTYPE values are the same as
their -march commands.
+. if ${CPUTYPE} == athlon-mp || ${CPUTYPE} == athlon-xp || ${CPUTYPE} ==
athlon-4
+MACHINE_CPU = athlon-xp k7 3dnow see mmx k6 k5 i586 i486 i386
^^^ typo
+. elif ${CPUTYPE} == athlon || ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
Can you think of a situtation where the athlon/athlon-xp capabilities
would need to be tested? i.e. what would they be used for?
Kris
msg36876/pgp0.pgp
Description: PGP signature
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Wed, Sep 11, 2002 at 10:56:48AM -0700, Kris Kennaway wrote:
+. elif ${CPUTYPE} == athlon || ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
Can you think of a situtation where the athlon/athlon-xp capabilities
would need to be tested? i.e. what would they be used for?
I do not quite understand the question. Are you asking if there are any
differences between athlon and athlon-xp? Or are you maybe asking if
there are any differences between athlon-4, athlon-xp, and athlon-mp?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 06:08:23PM -0700, Maxime Henrion wrote:
Forgot that one. Here is an updated patch. I'm quite sure that on the
Intel side, only the pentium 4 have sse2, but I don't know if any AMD
chip supports it yet. The attached patch only adds it for p4's.
Athlon-{X,M}P support SSE[1]. AMD x86-64 will be the first AMD processor
to support SSE2.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 01:30:26PM -0700, Kris Kennaway wrote:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
You can also add -msse, -msse2, -m3dnow to use those extensions. It would
appear that our bsd.cpu.mk file is out of date and is missing the newer
cpu types.
How about the following patch (I've only tested 'pentium3'):
I'd like to commit these Athlon changes. I find this much easier to
understand.
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.18
diff -u -r1.18 bsd.cpu.mk
--- bsd.cpu.mk 7 Sep 2002 01:26:10 - 1.18
+++ bsd.cpu.mk 8 Sep 2002 23:25:51 -
@@ -42,16 +42,8 @@
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == athlon-mp
-_CPUCFLAGS = -march=athlon-mp
-. elif ${CPUTYPE} == athlon-xp
-_CPUCFLAGS = -march=athlon-xp
-. elif ${CPUTYPE} == athlon-4
-_CPUCFLAGS = -march=athlon-4
-. elif ${CPUTYPE} == athlon-tbird
-_CPUCFLAGS = -march=athlon-tbird
-. elif ${CPUTYPE} == athlon
-_CPUCFLAGS = -march=athlon
+. if ${CPUTYPE} == athlon-mp || ${CPUTYPE} == athlon-xp || ${CPUTYPE} ==
+athlon-4 || ${CPUTYPE} == athlon
+_CPUCFLAGS = -march=${CPUTYPE}
. elif ${CPUTYPE} == k6-3
_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
@@ -105,16 +97,10 @@
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == athlon-mp
-MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon-xp
-MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon-4
-MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon-tbird
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
-. elif ${CPUTYPE} == athlon
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. if ${CPUTYPE} == athlon-mp || ${CPUTYPE} == athlon-xp || ${CPUTYPE} ==
+athlon-4
+MACHINE_CPU = athlon-xp k7 3dnow see mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon || ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = athlon k7 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-3
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
You can also add -msse, -msse2, -m3dnow to use those extensions. It would
appear that our bsd.cpu.mk file is out of date and is missing the newer
cpu types.
How about the following patch (I've only tested 'pentium3'):
Index: share/mk/bsd.cpu.mk
===
RCS file: /usr/home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -r1.16 bsd.cpu.mk
--- share/mk/bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ share/mk/bsd.cpu.mk 6 Sep 2002 20:25:46 -
-28,8 +28,8
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
-. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+. elif ${CPUTYPE} == k7
+CPUTYPE = athlon
. endif
. endif
-42,20 +42,30
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == athlon-tbird
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == athlon
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-3
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == p3
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == i586/mmx
Index: share/examples/etc/make.conf
===
RCS file: /usr/home/ncvs/src/share/examples/etc/make.conf,v
retrieving revision 1.198
diff -u -r1.198 make.conf
--- share/examples/etc/make.conf2 Aug 2002 18:04:22 - 1.198
+++ share/examples/etc/make.conf6 Sep 2002 20:25:19 -
-24,7 +24,7
# NO_CPU_CFLAGS variable below.
# Currently the following CPU types are recognized:
# Intel x86 architecture:
-# (AMD CPUs) k7 k6-2 k6 k5
+# (AMD CPUs) athlon-mp athlon-xp athlon-4 athlon-tbird athlon k6-3 k6-2 k6
+k5
# (Intel CPUs) p4 p3 p2 i686 i586/mmx i586 i486 i386
# Alpha/AXP architecture: ev6 pca56 ev56 ev5 ev45 ev4
# Intel ia64 architecture: itanium
msg36772/pgp0.pgp
Description: PGP signature
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
In the last episode (Sep 06), Kris Kennaway said: How about the following patch (I've only tested 'pentium3'): Index: share/mk/bsd.cpu.mk I've been using a similar patch ever since 3.* went into the tree with no problems. Haven't benchmarked the difference between pentiumpro and the other options, either, though. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Kris Kennaway wrote:
On Tue, Aug 06, 2002 at 06:55:11PM -0700, Peter Wemm wrote:
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
You can also add -msse, -msse2, -m3dnow to use those extensions. It would
appear that our bsd.cpu.mk file is out of date and is missing the newer
cpu types.
How about the following patch (I've only tested 'pentium3'):
[patch ripped]
I've got a very similar patch which I believe to be a bit more complete
because it also updates the MACHINE_CPU variable which lists the
features available on a particular CPU. I attach it to this mail.
Cheers,
Maxime
Index: bsd.cpu.mk
===
RCS file: /space2/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -p -r1.16 bsd.cpu.mk
--- bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ bsd.cpu.mk 11 Aug 2002 18:46:06 -
-28,8 +28,8 CPUTYPE = ultrasparc
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
-. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+. elif ${CPUTYPE} == k7
+CPUTYPE = athlon
. endif
. endif
-42,20 +42,30 CPUTYPE = k7
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == athlon-tbird
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == athlon
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-3
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == p3
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == i586/mmx
-93,8 +103,18 CFLAGS += ${_CPUCFLAGS}
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-xp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-4
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-tbird
+MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == k6-3
+MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Kris msg36779/pgp0.pgp Description: PGP signature
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Kris Kennaway wrote:
On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote:
I've got a very similar patch which I believe to be a bit more complete
because it also updates the MACHINE_CPU variable which lists the
features available on a particular CPU. I attach it to this mail.
Oops, I forgot that part. How about sse2 though?
Forgot that one. Here is an updated patch. I'm quite sure that on the
Intel side, only the pentium 4 have sse2, but I don't know if any AMD
chip supports it yet. The attached patch only adds it for p4's.
Cheers,
Maxime
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.16
diff -u -p -r1.16 bsd.cpu.mk
--- bsd.cpu.mk 2 Aug 2002 18:04:22 - 1.16
+++ bsd.cpu.mk 7 Sep 2002 01:05:43 -
-28,8 +28,8 CPUTYPE = ultrasparc
CPUTYPE = i686
. elif ${CPUTYPE} == pentium
CPUTYPE = i586
-. elif ${CPUTYPE} == athlon
-CPUTYPE = k7
+. elif ${CPUTYPE} == k7
+CPUTYPE = athlon
. endif
. endif
-42,20 +42,30 CPUTYPE = k7
# http://gcc.gnu.org/onlinedocs/gcc/RS-6000-and-PowerPC-Options.html
. if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+_CPUCFLAGS = -march=athlon-mp
+. elif ${CPUTYPE} == athlon-xp
+_CPUCFLAGS = -march=athlon-xp
+. elif ${CPUTYPE} == athlon-4
+_CPUCFLAGS = -march=athlon-4
+. elif ${CPUTYPE} == athlon-tbird
+_CPUCFLAGS = -march=athlon-tbird
+. elif ${CPUTYPE} == athlon
_CPUCFLAGS = -march=athlon
+. elif ${CPUTYPE} == k6-3
+_CPUCFLAGS = -march=k6-3
. elif ${CPUTYPE} == k6-2
-_CPUCFLAGS = -march=k6
+_CPUCFLAGS = -march=k6-2
. elif ${CPUTYPE} == k6
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == k5
_CPUCFLAGS = -march=pentium
. elif ${CPUTYPE} == p4
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium4
. elif ${CPUTYPE} == p3
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium3
. elif ${CPUTYPE} == p2
-_CPUCFLAGS = -march=pentiumpro
+_CPUCFLAGS = -march=pentium2
. elif ${CPUTYPE} == i686
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == i586/mmx
-93,8 +103,18 CFLAGS += ${_CPUCFLAGS}
# presence of a CPU feature.
.if ${MACHINE_ARCH} == i386
-. if ${CPUTYPE} == k7
+. if ${CPUTYPE} == athlon-mp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-xp
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-4
+MACHINE_CPU = sse k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon-tbird
MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == athlon
+MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. elif ${CPUTYPE} == k6-3
+MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6-2
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k6
-102,7 +122,7 MACHINE_CPU = mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == k5
MACHINE_CPU = k5 i586 i486 i386
. elif ${CPUTYPE} == p4
-MACHINE_CPU = sse i686 mmx i586 i486 i386
+MACHINE_CPU = sse2 sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == p3
MACHINE_CPU = sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == p2
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
On Fri, Sep 06, 2002 at 06:08:23PM -0700, Maxime Henrion wrote: Kris Kennaway wrote: On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Forgot that one. Here is an updated patch. I'm quite sure that on the Intel side, only the pentium 4 have sse2, but I don't know if any AMD chip supports it yet. The attached patch only adds it for p4's. Looks good to me! Kris msg36781/pgp0.pgp Description: PGP signature
Re: Updating bsd.cpu.mk (Re: -fomit-frame-pointer for the world build)
Maxime Henrion wrote: Kris Kennaway wrote: On Fri, Sep 06, 2002 at 05:55:47PM -0700, Maxime Henrion wrote: I've got a very similar patch which I believe to be a bit more complete because it also updates the MACHINE_CPU variable which lists the features available on a particular CPU. I attach it to this mail. Oops, I forgot that part. How about sse2 though? Forgot that one. Here is an updated patch. I'm quite sure that on the Intel side, only the pentium 4 have sse2, but I don't know if any AMD chip supports it yet. The attached patch only adds it for p4's. Both of the Hammer cpus support SSE2 FWIW. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Darren Pilgrim wrote: Terry Lambert wrote: Dmitry Morozovsky wrote: What are the drawbacks of building FreeBSD with -fomit-frame-pointer? The frame pointer is used for debugging, specifically for the stack traceback function to know arguments. Removing it means losing some debugging functionality. Next time try info gcc: If you don't have any need for debugging your software, is there any use for frame pointers? Is this something that can safely be used for both CFLAGS and COPTFLAGS? You can't use it in conjunction with calee pop, if you have mixed code. So it really depends on what other optimizations you throw in the mix, and then you have the problem of interfacing with assembly language code, as well -- the calling standard has to match, if it's asymmetric (i.e. not caller push, caller pop), and assembly code is hand-coded in this respect in most cases. The claimed savings are fictions. They are function call overhead savings assuming an average number of arguments and related pushed values, and they apply only to the call process itself. Most time in programs is spent in running, not calling functions, so if you expect an elimination of 18% overhead to make you programs that much faster, you are dreaming. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
On Sat, Aug 03, 2002 at 06:33:24PM -0700, Darren Pilgrim wrote: Terry Lambert wrote: Dmitry Morozovsky wrote: What are the drawbacks of building FreeBSD with -fomit-frame-pointer? The frame pointer is used for debugging, specifically for the stack traceback function to know arguments. Removing it means losing some debugging functionality. Next time try info gcc: If you don't have any need for debugging your software, is there any use for frame pointers? Is this something that can safely be used for both CFLAGS and COPTFLAGS? I would say be careful. I used to use -fomit-frame-pointer but I decided to stop. For one thing I didn't really notice any speedup. More importantly I ran one port that did not compile correctly with -fomit-frame-pointer. I don't quite remember which port but I think it was Mozilla, or possibly some other program using moderately complex C++. Anyway, with -fomit-frame-pointer the build consistently failed at exactly the same place. Without -fomit-frame-pointer it built just fine. Now this might well be a bug in that port, or it might be that some feature of C++ (exception handling would be my first guess) uses the frame pointer. This was some time ago so the problem, whatever it was, might well be fixed by now, but just bear this in mind if you decide to use -fomit-frame-pointer -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Terry Lambert wrote: TL Dmitry Morozovsky wrote: TL [ ... -fomit-frame-pointer ... ] TL Yes, Terry, I'd read this note. However, it does not clarify for me which TL exactly functionality is lost with omitting this. TL TL I tried to build some binaries with -fomit..., then tried to debug it a TL bit, and gdb shows me both backtrace stack and arguments, so I was in TL doubt a bit -- so here is my question ;-) TL TL Try it again on a SPARC or other RISC machine that pushes TL register window frames on the stack after a certain function TL call depth is achieved. TL TL I was pretty sure at one time that the PPC platform had a TL variant of this problem, as well. Well, this clarifies much more than I test -- the only platform I tried to check this was i386. TL If you want a definative answer, then the people to ask are TL the GCC implementors, who put the option into the compiler TL for a reason, and added the descriptive text to the .info TL file in the first place. I didn't doubt it ;-) TL Realize that this is a GCC issue, not a FreeBSD issue. What's the issue? Existence of -fomit... option? ;-) Actually, I was not specific enough in my initial question. It should sound something like: I presume building FreeBSD RELENG_4 world on i386 with -fomit-frame-pointer may lead to some undesired effects. But I neither found them in my (not so deep though) tests nor read info about it except GCC-info's note that you cite. 8-12% of code efficiency is not too small... Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Bakul Shah wrote: BS I tried to build some binaries with -fomit..., then tried to debug it a BS bit, and gdb shows me both backtrace stack and arguments, so I was in BS doubt a bit -- so here is my question ;-) BS BS I can answer that. Consider the following two functions: [snip very descriptive answer] Thanks Bakul, you'd give me a light. ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Terry Lambert wrote: Dmitry Morozovsky wrote: What are the drawbacks of building FreeBSD with -fomit-frame-pointer? The frame pointer is used for debugging, specifically for the stack traceback function to know arguments. Removing it means losing some debugging functionality. Next time try info gcc: If you don't have any need for debugging your software, is there any use for frame pointers? Is this something that can safely be used for both CFLAGS and COPTFLAGS? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
-fomit-frame-pointer for the world build
Hello there colleagues, I'd tried to search thru the web, but did not succeed enough. What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As far as I can see, it saves both space (which is not as worth as disk space got cheaper and cheaper) and execution time (which is, AFAICC, more important). I'd already done some tests, but not really deep. Would you please clarify this issue abit, or point me to any articles describing exact -fomit-frame-pointer behaviour? Thank you in advance. Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Dmitry Morozovsky wrote: What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As far as I can see, it saves both space (which is not as worth as disk space got cheaper and cheaper) and execution time (which is, AFAICC, more important). I'd already done some tests, but not really deep. Would you please clarify this issue abit, or point me to any articles describing exact -fomit-frame-pointer behaviour? The frame pointer is used for debugging, specifically for the stack traceback function to know arguments. Removing it means losing some debugging functionality. Next time try info gcc: `-fomit-frame-pointer' Don't keep the frame pointer in a register for functions that don't need one. This avoids the instructions to save, set up and restore frame pointers; it also makes an extra register available in many functions. *It also makes debugging impossible on some machines.* On some machines, such as the Vax, this flag has no effect, because the standard calling sequence automatically handles the frame pointer and nothing is saved by pretending it doesn't exist. The machine-description macro `FRAME_POINTER_REQUIRED' controls whether a target machine supports this flag. *Note Registers::. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
On Fri, 2 Aug 2002, Terry Lambert wrote: TL What are the drawbacks of building FreeBSD with -fomit-frame-pointer? As TL far as I can see, it saves both space (which is not as worth as disk space TL got cheaper and cheaper) and execution time (which is, AFAICC, more TL important). TL TL I'd already done some tests, but not really deep. TL TL Would you please clarify this issue abit, or point me to any articles TL describing exact -fomit-frame-pointer behaviour? TL TL The frame pointer is used for debugging, specifically for the TL stack traceback function to know arguments. Removing it means TL losing some debugging functionality. Next time try info gcc: TL TL `-fomit-frame-pointer' TL Don't keep the frame pointer in a register for functions that TL don't need one. This avoids the instructions to save, set up and TL restore frame pointers; it also makes an extra register available TL in many functions. *It also makes debugging impossible on some TL machines.* TL TL On some machines, such as the Vax, this flag has no effect, because TL the standard calling sequence automatically handles the frame TL pointer and nothing is saved by pretending it doesn't exist. The TL machine-description macro `FRAME_POINTER_REQUIRED' controls TL whether a target machine supports this flag. *Note Registers::. Yes, Terry, I'd read this note. However, it does not clarify for me which exactly functionality is lost with omitting this. I tried to build some binaries with -fomit..., then tried to debug it a bit, and gdb shows me both backtrace stack and arguments, so I was in doubt a bit -- so here is my question ;-) Sincerely, D.Marck [DM5020, DM268-RIPE, DM3-RIPN] *** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- [EMAIL PROTECTED] *** To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
Dmitry Morozovsky wrote: [ ... -fomit-frame-pointer ... ] Yes, Terry, I'd read this note. However, it does not clarify for me which exactly functionality is lost with omitting this. I tried to build some binaries with -fomit..., then tried to debug it a bit, and gdb shows me both backtrace stack and arguments, so I was in doubt a bit -- so here is my question ;-) Try it again on a SPARC or other RISC machine that pushes register window frames on the stack after a certain function call depth is achieved. I was pretty sure at one time that the PPC platform had a variant of this problem, as well. If you want a definative answer, then the people to ask are the GCC implementors, who put the option into the compiler for a reason, and added the descriptive text to the .info file in the first place. Realize that this is a GCC issue, not a FreeBSD issue. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: -fomit-frame-pointer for the world build
I tried to build some binaries with -fomit..., then tried to debug it a
bit, and gdb shows me both backtrace stack and arguments, so I was in
doubt a bit -- so here is my question ;-)
I can answer that. Consider the following two functions:
f(int n)
{
int x; int y;
... // no calls to other functions, no nested
// declaration of variables
}
g(int n)
{
int x;
int array[n]; // allowed in gcc
int y;
... // no calls to other functions, no nested
// declaration of variables
}
First assume stack grows toward higher addresses. For the
other direction just swap - and + in computing local
var addresses.
Note that when using a frame ptr (also called a dynamic
link in compiler lingo), one generally needs to something
like this:
on entry:
push frame ptr
frame ptr = stack ptr
stack ptr += framesize
just before returning:
stack ptr -= framesize
frame ptr = pop
return
Its caller then removes arguments on the stack.
Now notice that the framesize of f() is a constant! To
address a local variable(or any args), one can either use
frame ptr + offset1,
where offset1 = its distance from the frame ptr,
note that for arg n the distance is -ve.
or use
stack ptr - offset2,
where offset2 = its distance from the stack ptr.
Given that the framesize is constant, we can always compute
where the frame starts from the stack ptr and hence we don't
need the frame ptr. Debugging should also work if the
framesize constant is made known to the debugger -- usually
by storing it just before the generated code for the
function. Consequently you don't need to save and restore
the caller's frame ptr -- hence the time savings.
But if the framesize is not a constant (such as when a
variable sized array is declared as in g()), things get a bit
complicated. If we have a frame ptr as well as a stack ptr,
you can address x as well as y with a constant offset. If
you remove the frame pointer, you need to use the value of n
in computing the offset of x. Further, the debugger may find
it very difficult to locate the framesize (but it can be
done) to unravel the stack. So you may or may not see any
time savings.
Note that there are tricks to making the framesize constant
even when there are variables declared in nested blocks.
This is done by hoisting the vars to the function level.
My view is that -fomit-frame-pointer is almost always worth
it provided gdb is smart enough to locate all the frames.
If this is not clear enough, try drawing a picture of how
the frames are popped and pushed on a stack as well as stare
the generated code until you 'get it'!
-- bakul
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
