Commit Graph

29 Commits

Author SHA1 Message Date
Maxime Henrion
96f5595bf7 Since -march=pentium4 is supposed to be fixed with GCC 3.3, and
since people have been reporting success with it, re-enable the
pentium4 optimization.
2003-07-13 10:34:09 +00:00
Eric Anholt
b1aff8bff1 Change -march=pentium4 to -march=pentium3 when CPUTYPE==p4, because gcc 3.2 is
known to produce broken code with -march=pentium4.  Add a note explaining this.
This should be removed when we update to gcc 3.3 or the bug is otherwise fixed.

Approved by:	re
2003-05-22 16:56:46 +00:00
Peter Wemm
721b850f30 s/x86[-_]64/amd64/ for MACHINE_ARCH and MACHINE_CPU .ifdefs.
Noticed by:  ru
Approved by: re (amd64-specific low risk stuff)
2003-05-20 01:46:16 +00:00
David E. O'Brien
ae7906208d Add CPUTYPE support for "athlon-tbird", as GCC makes the distinction.
PR:		50801
Submitted by:	Glenn Johnson <glennpj@charter.net>
2003-04-14 17:36:29 +00:00
David E. O'Brien
7d40314e32 Default the userland to 486 capabilities. 2003-04-11 21:28:17 +00:00
David E. O'Brien
dde8112b23 Globally use -mieee in /usr/src for Alpha. 2003-03-29 03:14:24 +00:00
David E. O'Brien
44db0c5c9a Reduce "code duplication" for AMD CPU's. 2003-03-29 03:13:19 +00:00
John Baldwin
23bfdc2d66 Whitespace-only indention fixups for revision 1.20. This lets the 1.20
diff actually be readable.
2002-09-18 20:51:25 +00:00
John Baldwin
f41fb58cd1 Oops, fix userland _CPUCFLAGS. Move adding of _CPUCFLAGS to bottom of
file after end of empty CPUTYPE else clause.
2002-09-18 20:48:54 +00:00
John Baldwin
eb28bc3e98 For the default case of CPUTYPE not being set, don't define CPUTYPE to the
lowest value in order to get the right MACHINE_CPU values since setting
CPUTYPE can result in problems later in the buildkernel case.  Instead,
set MACHINE_CPU directly and leave CPUTYPE alone.

Tested by:	mbr
2002-09-18 20:44:46 +00:00
David E. O'Brien
fb3d225909 Add support for the AMD x86-64 Hammer platform. 2002-09-11 04:57:09 +00:00
Kris Kennaway
0dafadb731 Add support for ev67 and ev45 CPUTYPEs (new in gcc3) 2002-09-07 01:26:11 +00:00
Maxime Henrion
8e4b67a2a3 Update to use all the new CPU optimizations of GCC3.
Reviewed by:	kris
2002-09-07 01:15:29 +00:00
Ruslan Ermilov
32f8ca450d TARGET_CPUTYPE should exist solely in Makefile.inc1, similar to
TARGET_ARCH and TARGET.  This is problematic when one has the =
(unconditional) type of assigment for CPUTYPE in /etc/make.conf.
(This would override what was set on the command line to "make
buildworld".)

Add a (horrible) kludge to Makefile.inc1 to check the type of
assignment for CPUTYPE (only for those who attempts to set it to
a different value).  Fix an example make.conf.  Fix the kernel's
build-tools target (aicasm only at the moment) to catch up with
bsd.cpu.mk,v 1.15 (BOOTSTRAPPING replaced with NO_CPU_CFLAGS in
Makefile.inc1's BMAKE).

Reviewed by:	jhb
2002-08-02 18:04:22 +00:00
John Baldwin
22e256fded - Define NO_CPU_CFLAGS during BMAKE and TMAKE (and thus XMAKE) so that
bsd.cpu.mk doesn't have to worry about compilers other than the current
  version.
- Allow TARGET_CPUTYPE to override CPUTYPE in bsd.cpu.mk.
- Treat an empty CPUTYPE the same as an undefined CPUTYPE.
- For buildworld, buildkernel, etc., define TARGET_CPUTYPE to CPUTYPE for
  native builds and define it to be empty for cross-builds.
  TARGET_CPUTYPE is only defined if it is not already defined via the
  commandline or environment.
2002-07-31 03:56:03 +00:00
John Baldwin
9bd85872d1 - Fixup whitespace after previous commit.
- To minimize whitespace changes, remove a test that didn't define
  _CPUCFLAGS if both NO_CPU_CFLAGS and NO_CPU_COPTFLAGS were defined
  since it is redundant (we don't use _CPUCFLAGS if those are defined).
2002-07-27 22:15:42 +00:00
John Baldwin
8605c6b2ad If there is not a CPUTYPE defined by default, then allow for _CPUCFLAGS
to tune for more advanced processors while still supporting the minimum
processor in an architecture.  We can do this with the '-mtune=' option
to gcc for alpha, sparc64, and powerpc and with the mis-named '-mcpu='
option for i386.

This defaults to tuning i386 builds for i686 machines though not using
any instructions that aren't found on an 80386.  For alpha it defaults
to tuning for an EV5.

Approved by:	peter
Peril sensitive sunglasses borrowed from:	peter
2002-07-27 22:04:05 +00:00
Maxim Sobolev
6e542f8c06 In gcc 3.1 Pentium/MMX now has its own -march=XXX option. 2002-06-13 08:35:36 +00:00
Ruslan Ermilov
ce17d4f3d3 Bootstrapping aid for those with Athlon upgrading from gcc 2.95.x.
Prodded by:	gordon
2002-05-31 12:50:24 +00:00
David E. O'Brien
22e5252fed Default Alpha compiles to ev5.
EV5 binaries will run on EV4[5], but the timing assumptions do pessimize
running on EV4[5].

Tested by:	ticso
2002-05-15 18:16:43 +00:00
David E. O'Brien
ab4448f3e4 Add pointers to GCC's allowable values for -march, and restore structure
of rev 1.7 until someone can sit down and think thru all the GCC 3.1
related changes.
2002-05-11 20:18:54 +00:00
David E. O'Brien
2c0b3c611a With GCC 3.1, we can now treat AMD Athlon and an Athlon.
Submitted by:	Steven G. Kargl <kargl@troutmask.apl.washington.edu>
2002-05-11 20:05:17 +00:00
David E. O'Brien
a25fa515ee Add the beginnings of Sparc64 support. 2002-05-10 01:31:40 +00:00
Ruslan Ermilov
cf80b5b504 Optimize for i486 better (-m486 is just another deprecated
synonym for -mcpu=i486).

PR:		i386/37212
Submitted by:	Matthias Andree <matthias.andree@web.de>
MFC after:	3 days
2002-04-18 09:37:15 +00:00
Kris Kennaway
d64b406847 Pentium II's do not support SSE, that came in with the PIII
Submitted by:	sf
2001-03-21 08:29:39 +00:00
Kris Kennaway
5ca7924a91 Use CPUTYPE to add appropriate compiler flags to COPTFLAGS for kernel
builds.  This may be disabled using the NO_CPU_COPTFLAGS variable.

Reviewed by:	arch
2001-03-12 07:47:09 +00:00
Maxim Sobolev
d6511a3c8d AMD K6/K6-2/Duron/Athlon CPUs support MMX too.
Missed by:	kris
2001-03-10 11:49:05 +00:00
Kris Kennaway
181b6941c7 Add definitions and support for the AMD k6-2, Pentium MMX (i586/MMX),
and Pentium II, III and IV processors (p2, p3, p4), as well as 'mmx' and
'3dnow' MACHINE_CPU tags as appropriate.  In the near future this will
be used to control various ports which have MMX/3dNow optimizations,
instead of the ad-hoc methods currently used.

Reviewed by:    peter
2001-02-27 11:21:47 +00:00
Kris Kennaway
62d90fb793 Overhaul the MACHINE_CPU behaviour:
* Rip out MACHINE_CPU stuff from sys.mk and include a new <bsd.cpu.mk>
  after we pull in /etc/make.conf.  We need to do it afterwards so we can
  react to the user setting of the:

* CPUTYPE variable, which contains the CPU type which the user wants to
  optimize for.  For example, if you want your binaries to only run on an
  i686-class machine (or higher), set this to i686.  If you want to support
  running binaries on a variety of CPU generations, set this to the lowest
  common denominator.  Supported values are listed in make.conf.

* bsd.cpu.mk does the expansion of CPUTYPE into MACHINE_CPU using the
  (hopefully) correct unordered list of CPU types which should be used on
  that CPU.  For example, an AMD k6 CPU wants any of the following:
    k6 k5 i586 i486 i386
  This is still an unordered list so the client makefile logic is simple -
  client makefiles need to test for the various elements of the set in
  decreasing order of priority using ${MACHINE_CPU:M<foo>}, as before.
  The various MACHINE_CPU lists are believed to be correct, but should be
  checked.

* If NO_CPU_CFLAGS is not defined, add relevant gcc compiler optimization
  settings by default (e.g. -karch=k6 for CPUTYPE=k6, etc).  Release
  builders and developers of third-party software need to make sure not to
  enable CPU-specific optimization when generating code intended to be
  portable.  We probably need to move to an /etc/world.conf to allow the
  optimization stuff to be applied separately to world/kernel and external
  compilations, but it's not any worse a problem than it was before.

* Add coverage for the ia64/itanium MACHINE_ARCH/CPUTYPE.

* Add CPUTYPE support for all of the CPU types supported by FreeBSD and gcc
  (only i386, alpha and ia64 first, since those are the minimally-working
  ports.  Other architecture porters, please feel free to add the relevant
  gunk for your platform).

Reviewed by:    jhb, obrien
2001-02-22 11:14:25 +00:00