Commit graph

67 commits

Author SHA1 Message Date
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