svn commit: r353936 - head/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch

[Warner Losh]

On Thu, Oct 24, 2019 at 2:26 AM Alexey Dokuchaev <danfe at freebsd.org> wrote:

> On Wed, Oct 23, 2019 at 04:57:12PM +0000, Dimitry Andric wrote:
> > New Revision: 353936
> > URL: https://svnweb.freebsd.org/changeset/base/353936
> >
> > Log:
> >   Bump clang's default target CPU for the i386 architecture (aka "x86")
> to
> >   i686, as per the discussion on the freebsd-arch mailing list.  Earlier
> >   in r352030, I had already bumped it to i586, to work around missing
> >   atomic 64 bit functions for the i386 architecture.
>
> Why i686, not i586?  i486 lacking 64-bit atomics is a sound and valid
> reason, but I don't understand why i586 wasn't chosen, and quick review
> of that -arch thread did not help.  Could you shed some more light here?
>

There were several notions at play here. First, the rest of the i386
ecosystem has defaulted to i686 for a long time. This aligns us better when
them. Next, the share of Pentium processors in FreeBSD is super small, and
confined to firewall embedded boxes. These boxes aren't installed from our
base installation media and have custom builds already. The arch@ thread
suggested that people would be OK building their own packages. A recent
survey of available hardware suggests that the last 586 core systems (Geode
LX was the latest I could find) were sold by people like PC Engines in 2018
(or maybe 2019), those these were trailing edge, EOL'd systems that hadn't
been recommended for new deployments for a few years prior. This tells us
that the need for us to retain 586 compatibility by default is low, but the
need to have it available is still high enough to not remove support
entirely. People are transitioning away from this embedded gear now that
the CPUs have gone EOL, though the transition will likely take years to
complete.

The 486 cores EOLd by 2010, so that part of things is a non-issue: only the
hardiest of hardware is still around, and it's not being
aggressively upgraded to -current.

i686 support by default allows better code generation and increased
performance. The biggest thing being using CMOVxx instructions to avoid a
pipeline miss due to branching, though there's likely others.

By moving to i686 by default, we have only one bump instead of two. We
should have bumped to 586 in the 11 time frame, using similar analysis to
the above, but we didn't. Doing one big bump means we won't have to go back
to the well to have another discussion about it in the future. If these
discussions were better in the past, then that wouldn't be a big deal.
However, the project is a little dysfunctional in this area and the desire
to bump to 686 to avoid some of that in a platform that's rapidly ramping
down even in its core areas played into this a bit. Chances are this will
be the last minimum bump as well before i386 is removed from the tree as
irrelevant (some years from now, but the day will come). There's no good
next higher tier to land on anyway....

So that's where we are: a mix of technical and political reasons were why
we bumped up to i686 by default and retained the ability to still deploy on
i586-cores for the small portion of our user base that will need to do so
after 13 is released.

Warner