Date: Sat, 24 Feb 2007 17:58:01 -0800 From: "Steven Hillis" <evultrole@gmail.com> To: freebsd-sparc64@freebsd.org Subject: Re: good (working) CFLAGS for SPARC64 Message-ID: <340594530702241758t422d9332u1dc0cc34c5047006@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
------=_Part_51376_26925194.1172368681742
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Christian,
I've spent a little more time on this today (waiting on source compiles each
time I changed something took forever, so it took far longer than I would
have liked). The following lines are what I was talking about before (found
in contrib/gcc/config/sparc/sparc.h):
/* Note that TARGET_CPU_v9 is assumed to start the list of 64-bit
capable cpu's. */
#define TARGET_CPU_sparc 0
#define TARGET_CPU_v7 0 /* alias for previous */
#define TARGET_CPU_sparclet 1
#define TARGET_CPU_sparclite 2
#define TARGET_CPU_v8 3 /* generic v8 implementation */
#define TARGET_CPU_supersparc 4
#define TARGET_CPU_hypersparc 5
#define TARGET_CPU_sparc86x 6
#define TARGET_CPU_sparclite86x 6
#define TARGET_CPU_v9 7 /* generic v9 implementation */
#define TARGET_CPU_sparcv9 7 /* alias */
#define TARGET_CPU_sparc64 7 /* alias */
#define TARGET_CPU_ultrasparc 8
#define TARGET_CPU_ultrasparc3 9
Basically, in order for any sparc system to be 64-bit enabled it has to be
at least v9 compiled, hence FreeBSD/Sparc64, NetBSD/Sparc64, and
OpenBSD/Sparc64 must all be v9 compiled... which is what I was trying to get
at earlier.
Now, that aside, -mtune=ultrasparc -mcpu=ultrasparc didn't change the speed
of anything in any significant way (if there was a change in the programs I
tested it was too small to be noticable), whereas the change from just -pipe
to -pipe -O2 gave a 275% increase in speed in things like lame... so, you
can use my fix for mcpu if you want, but since it defaults to v9 (has to for
64 bit support) and there isn't really any difference between generic v9 and
ultrasparc (first v9) you won't gain much, if anything (I honestly noticed
no difference at all).
Anyway, I fixed the errors in three different ways, one was about 5 files
changed, one 91 files changed, then bothered to actually look at the
difference between the OpenBSD/NetBSD and FreeBSD implementation. For
whatever reason the freebsd config goes with CPP_CPU64_DEFAULT_SPEC with
many options, whereas the others go with a TARGET_CPP_BUILTIN... now, you'd
assume they would be two ways to reach the same end, but they aren't.... the
freebsd way of doing it allows the __sparc64__ spec to be overwritten with
mcpu flags, while the others don't as the __sparc64__ is builtin and present
in all possible sparc configurations (as I understand it).
So, the basic fix was just updating the
/usr/src/contrib/gcc/config/sparc/freebsd.h file with this (diff output):
*** contrib/gcc/config/sparc/freebsd.h Tue Jul 27 22:00:13 2004
--- contrib/gcc/config/sparc/temp/freebsd.h Sat Feb 24 16:56:33 2007
***************
*** 34,44 ****
#undef FBSD_TARGET_CPU_CPP_BUILTINS
#define FBSD_TARGET_CPU_CPP_BUILTINS() \
do \
{ \
builtin_define ("__LP64__"); \
! } \
while (0)
#define LINK_SPEC
"%(link_arch) \
%{!mno-relax:%{!r:-relax}} \
%{p:%nconsider using `-pg' instead of `-p' with
gprof(1)} \
--- 34,48 ----
#undef FBSD_TARGET_CPU_CPP_BUILTINS
#define FBSD_TARGET_CPU_CPP_BUILTINS() \
do \
{ \
builtin_define ("__LP64__"); \
! builtin_define ("__sparc64__"); \
! builtin_define ("__sparc_v9__"); \
! builtin_define ("__sparcv9"); \
! builtin_define ("__arch64__"); \
! } \
while (0)
#define LINK_SPEC
"%(link_arch) \
%{!mno-relax:%{!r:-relax}} \
%{p:%nconsider using `-pg' instead of `-p' with
gprof(1)} \
Now, unless there is some super important reason those are not in the
freebsd config file (like breaking compatibility with the new T1s) they
really should be put in. Even if it breaks the new sparc cpus, at least
builtin_define ("__sparc64__"); should be there at the least, that won't
break anything (from what I can tell) and would solve any problems like
this. Even if the mcpu flags are unneeded because it defaults to v9 support
it doesn't make any sense to leave the system in a state where adding a
duplicate flag breaks things.
So, Chris, drop those into the file it should fix it, and I'm going to go
ahead and file a bug report on this along with the fix, the maintainers can
decide what to do with it from there I guess...
------=_Part_51376_26925194.1172368681742
Content-Type: text/plain; name=freebsd.h.diff.txt; charset=ANSI_X3.4-1968
Content-Transfer-Encoding: base64
X-Attachment-Id: f_eyku42v9
Content-Disposition: attachment; filename="freebsd.h.diff.txt"
KioqIGNvbnRyaWIvZ2NjL2NvbmZpZy9zcGFyYy9mcmVlYnNkLmgJVHVlIEp1bCAyNyAyMjowMDox
MyAyMDA0Ci0tLSBjb250cmliL2djYy9jb25maWcvc3BhcmMvdGVtcC9mcmVlYnNkLmgJU2F0IEZl
YiAyNCAxNjo1NjozMyAyMDA3CioqKioqKioqKioqKioqKgoqKiogMzQsNDQgKioqKgogICN1bmRl
ZiAgRkJTRF9UQVJHRVRfQ1BVX0NQUF9CVUlMVElOUwogICNkZWZpbmUgRkJTRF9UQVJHRVRfQ1BV
X0NQUF9CVUlMVElOUygpCQlcCiAgICBkbwkJCQkJCVwKICAgICAgewkJCQkJCVwKICAgICAgICBi
dWlsdGluX2RlZmluZSAoIl9fTFA2NF9fIik7CQlcCiEgICAgIH0JCQkJCQlcCiAgICB3aGlsZSAo
MCkKICAKICAjZGVmaW5lIExJTktfU1BFQyAiJShsaW5rX2FyY2gpCQkJCQkJXAogICAgJXshbW5v
LXJlbGF4OiV7IXI6LXJlbGF4fX0JCQkJCQlcCiAgICAle3A6JW5jb25zaWRlciB1c2luZyBgLXBn
JyBpbnN0ZWFkIG9mIGAtcCcgd2l0aCBncHJvZigxKX0JCQkJXAotLS0gMzQsNDggLS0tLQogICN1
bmRlZiAgRkJTRF9UQVJHRVRfQ1BVX0NQUF9CVUlMVElOUwogICNkZWZpbmUgRkJTRF9UQVJHRVRf
Q1BVX0NQUF9CVUlMVElOUygpCQlcCiAgICBkbwkJCQkJCVwKICAgICAgewkJCQkJCVwKICAgICAg
ICBidWlsdGluX2RlZmluZSAoIl9fTFA2NF9fIik7CQlcCiEgICAgICAgYnVpbHRpbl9kZWZpbmUg
KCJfX3NwYXJjNjRfXyIpOyAgICAgICAgICAgICAgIFwKISAgICAgICBidWlsdGluX2RlZmluZSAo
Il9fc3BhcmNfdjlfXyIpOyAgICAgICAgICAgICAgXAohICAgICAgIGJ1aWx0aW5fZGVmaW5lICgi
X19zcGFyY3Y5Iik7ICAgICAgICAgICAgICAgICBcCiEgICAgICAgYnVpbHRpbl9kZWZpbmUgKCJf
X2FyY2g2NF9fIik7ICAgICAgICAgIFwKISAgICAgIH0JCQkJCQlcCiAgICB3aGlsZSAoMCkKICAK
ICAjZGVmaW5lIExJTktfU1BFQyAiJShsaW5rX2FyY2gpCQkJCQkJXAogICAgJXshbW5vLXJlbGF4
OiV7IXI6LXJlbGF4fX0JCQkJCQlcCiAgICAle3A6JW5jb25zaWRlciB1c2luZyBgLXBnJyBpbnN0
ZWFkIG9mIGAtcCcgd2l0aCBncHJvZigxKX0JCQkJXAo=
------=_Part_51376_26925194.1172368681742--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?340594530702241758t422d9332u1dc0cc34c5047006>