From owner-svn-src-all@freebsd.org Thu Oct 24 15:14:21 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 2E51A16F728 for ; Thu, 24 Oct 2019 15:14:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46zW4D1hwlz3Nlv for ; Thu, 24 Oct 2019 15:14:19 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x832.google.com with SMTP id w14so38344722qto.9 for ; Thu, 24 Oct 2019 08:14:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uXy0Y5xsVRztx3n82NB0Ju3DwprUJLICwynudZYUIe4=; b=df1T+OGuDKKEek83/l4zmw+dNTKfbtJEAwPoXHoUhLCd4LaklVewwzcBefvWCEV/1Y Ls6ukCxbP9cKIxwnSgC0ffj4MmFQtupwyH+piRvfrkEZ993So77+Nno05ZYdGQsqdKoh xvfmrhstZ1HTc72PBIyEzTdpnOOHmUVNDUHDPdxxm31Z4ezXxcvwmZkcOS2akjraTDpN OQpE6ls8ohOf/t4P4yFZwRoG+21jzb3wF29ZP/JwDd3A+1ijLmasjb5fhmOLg0eNxV4P GLz7Vzm8AuSDhpie4ZtOBl8oFMn1eyAeL0fscTy+GtxlAw1qCYSOpgX6OrxWkDpGJAs7 vkKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=uXy0Y5xsVRztx3n82NB0Ju3DwprUJLICwynudZYUIe4=; b=huu4ZKW92wNNcBr4Latyk9CzqIC3avKQgqcpNFXCvNzd208P6V5CKLfb3AeIs8mFWK adpaiBhel0Zxjf0NlpLNJU1aUcGM9T94CzKsjnByvL67KHZ27yMxsMrpJTWkeYZNsPNU sJOyi6xa15PWJhSlI0qIZcNEASmyGC4WRJ3qHUKfhI5kQOf7HXJCq5Z9nQ+69ddrLt1N My9HsuK55xsFJdGMO8S+8LU1ckyLFitTpB8ySQDXUDzjWKrKlxcIkshE5tVZRAI7Div8 zeicUAiefOHlOSLMG9mFv7JdF6eqZvlKOc8b73pMBkFbUAXjgz+OuJdUKlC2UDZdFLJ7 Qw8A== X-Gm-Message-State: APjAAAWYZURia0w0OJqYX1XsVKqil0ucu8MayJ6iTUOPMdkcF3IRBMO1 5R+mgGhatJOub6hsGszVyukIzUpdIN7ZTJUmtbZWyg== X-Google-Smtp-Source: APXvYqyNP/fYXbMTiQQYcLJjaIk00IGMj1RXoPpJYptkpWKl8uoWvMbrhlXHYydlJ4svHtk0/uzJvVHELzVJ94YD4gA= X-Received: by 2002:a0c:eda9:: with SMTP id h9mr12916984qvr.125.1571930058317; Thu, 24 Oct 2019 08:14:18 -0700 (PDT) MIME-Version: 1.0 References: <201910231657.x9NGvCMD039111@repo.freebsd.org> <20191024082609.GA63459@FreeBSD.org> In-Reply-To: <20191024082609.GA63459@FreeBSD.org> From: Warner Losh Date: Thu, 24 Oct 2019 09:14:07 -0600 Message-ID: Subject: Re: svn commit: r353936 - head/contrib/llvm/tools/clang/lib/Driver/ToolChains/Arch To: Alexey Dokuchaev Cc: Dimitry Andric , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 46zW4D1hwlz3Nlv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=df1T+OGu; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::832) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-3.78 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; URI_COUNT_ODD(1.00)[3]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; RCVD_IN_DNSWL_NONE(0.00)[2.3.8.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; IP_SCORE(-2.78)[ip: (-9.38), ipnet: 2607:f8b0::/32(-2.41), asn: 15169(-2.06), country: US(-0.05)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Oct 2019 15:14:21 -0000 On Thu, Oct 24, 2019 at 2:26 AM Alexey Dokuchaev 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