Date: Thu, 24 Oct 2019 09:14:07 -0600 From: Warner Losh <imp@bsdimp.com> To: Alexey Dokuchaev <danfe@freebsd.org> Cc: Dimitry Andric <dim@freebsd.org>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r353936 - head/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch Message-ID: <CANCZdfrqdy9MBX6JfrY%2BkBCQY=xZABAnS=VF7U4KWZzVo9Qj6w@mail.gmail.com> In-Reply-To: <20191024082609.GA63459@FreeBSD.org> References: <201910231657.x9NGvCMD039111@repo.freebsd.org> <20191024082609.GA63459@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Oct 24, 2019 at 2:26 AM Alexey Dokuchaev <danfe@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrqdy9MBX6JfrY%2BkBCQY=xZABAnS=VF7U4KWZzVo9Qj6w>