Re: Release Building and /etc/make.conf

From: John Baldwin (jhb_at_FreeBSD.org)
Date: 01/20/04

  • Next message: John Baldwin: "Re: Sleeping on "stopevent" with non-sleepable locks held" 
    To: Bruce Evans <bde@zeta.org.au>, Ruslan Ermilov <ru@freebsd.org>
Date: Tue, 20 Jan 2004 13:19:52 -0500

    On Tuesday 20 January 2004 09:41 am, Bruce Evans wrote:
    > On Mon, 19 Jan 2004, Ruslan Ermilov wrote:
    > > On Mon, Jan 19, 2004 at 06:23:30PM +1100, Chris Knight wrote:
    > > > Howdy,
    > > >
    > > > I'm just doing a release build of 5.2 and have noticed that
    > > > from Stage 4.2 onwards, -mcpu=pentiumpro is added to the cc
    > > > command line.
    > > > The only place I can see this being set is in /etc/make.conf
    > > > which is outside the sandbox.
    > > > I was expecting the release build to be CPU agnostic, but
    > > > this doesn't appear to be the case. Any way of overriding
    > > > this without modifying /etc/make.conf?
    >
    > Is there a problem with modifying /etc/make.conf? As maxim said,
    > you can avoid /etc/make.conf using __MAKE_CONF. You can also set
    > CPUTYPE in the environment. Beware that settings in the enviroment
    > might not have precedence over settings in /etc/make.conf. Anyway,
    > -mcpu=pentiumpro is not actually set in /etc/make.conf. As ru doesn't
    >
    > quite say, it is set in bsd.cpu.mk:
    > > There's a substantional difference between -mcpu and -march:
    > > : -mcpu=cpu type
    > > : Assume the defaults for the machine type CPU TYPE when schedul-
    > > : ing instructions. The choices for CPU TYPE are: i386, i486,
    > > : i586 (pentium), pentium, i686 (pentiumpro), and pentiumpro.
    > > : While picking a specific CPU TYPE will schedule things appropri-
    > > : ately for that particular chip, the compiler will not generate
    > >
    > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > >
    > > : any code that does not run on the i386 without the -march=cpu
    > >
    > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    > >
    > > : type option being used.
    > > :
    > > : -march=cpu type
    > > : Generate instructions for the machine type CPU TYPE. The choic-
    > > : es for CPU TYPE are: i386, i486, pentium, and pentiumpro. Spec-
    > > : ifying -march=cpu type implies -mcpu=cpu type.
    > >
    > > Please also see the commit log for bsd.cpu.mk,v 1.13.
    >
    > Also see gcc.info, since the above seems to be from gcc.1 which is as out
    > of date as a pentiumpro.
    >
    > bsd.cpu.mk should rarely be edited, but /etc.make.conf is per-machine so
    > you can put anything you want in it. However, defaulting to
    > -mcpu=pentiumpro is just a bug, so I edit it out of bsd.cpu.mk. It
    > just micro-pessimizes for all CPUs that aren't pentium pros. This is
    > almost harmless for i386's because no one uses them, and almost harmless
    > for P3's and maybe P4's because they share some bottlenecks with
    > pentiumpros, but Athlons handle naive i386 code better than pentiums so
    > many of the pentiumpro optimizations are pessimizations for athlons.

    The choice if ppro was Peter's suggestion. Feel free to offer a better
    default CPU to tune for.

    > Note that CPUTYPE has worse bugs for i386's. Setting it to a supported
    > CPU gives -march instead of -mcpu, so using it gives unportable binaries,
    > and bsd.cpu.mk provides no way to get the corresponding -mcpu settings.
    > OTOH, CPUTYPE for alphas gives only -mcpu.

    That is by design. Note that on all non-i386 architectures such as alpha,
    etc. -mcpu means the same thing as -march. The other architectures use
    -mtune to get the same effect as -mcpu on i386. 

    -- 
John Baldwin <jhb@FreeBSD.org>  <><  http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve"  =  http://www.FreeBSD.org
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: John Baldwin: "Re: Sleeping on "stopevent" with non-sleepable locks held"