From owner-freebsd-current@FreeBSD.ORG Sat Aug 24 15:42:12 2013 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 007B2662 for ; Sat, 24 Aug 2013 15:42:11 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BC1DE2463 for ; Sat, 24 Aug 2013 15:42:11 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id a14so2593226iee.40 for ; Sat, 24 Aug 2013 08:42:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=cECSnYUFag5Y5kHUjMRJNA+BQ8xOAnDFKMSgkETnEIo=; b=fWSVgh7B2hHWXjqs/syg90YnV5DJSicl1oeE59GckaTz004drTsf5+9XffFST7PV7a qQhhRHcjTkfwthMEpI4g5LAEPeKMKbw9iXMTC0MC3wZbtAX495OqTUmeTHP9baJAkSSi JJ82MkD2jtcSCUmaJiXrrGdjr7VefLSpCFDYrBRM519zkVLEbYH5u2HoKbovc8CiQ8Fj cAmwU3t5i1f2zLxn7re2DMoWTDslgVqhLiVtHsIZlpWJLhwjOFB1hAKmQNPpAnaqLp4I H+a68caQPok6w9xUVhDTsxNpukkMJ8Pjjdsl5yqIwvfY3K6zkvSQZ52iThjEQdOIGGXl t82w== X-Gm-Message-State: ALoCoQncN0SsrjRG/vxS4OpJvbliCF38SGk1N10D6lURONljXGKn1a9yZu3x496DGH5y1ZqifI2i X-Received: by 10.50.119.42 with SMTP id kr10mr1695285igb.20.1377358925608; Sat, 24 Aug 2013 08:42:05 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id p10sm4925151igx.4.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 24 Aug 2013 08:42:04 -0700 (PDT) Sender: Warner Losh Subject: Re: patch to add AES intrinsics to gcc Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> Date: Sat, 24 Aug 2013 09:42:02 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <5CE4B5FA-9DA0-45E4-8D67-161E0829FE6B@FreeBSD.org> <5217DBAB.5030607@freebsd.org> <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> To: David Chisnall X-Mailer: Apple Mail (2.1085) Cc: toolchain@freebsd.org, John-Mark Gurney , Alfred Perlstein , "re@FreeBSD.org Engineering Team" , current@freebsd.org X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Aug 2013 15:42:12 -0000 On Aug 24, 2013, at 4:05 AM, David Chisnall wrote: > On 23 Aug 2013, at 23:37, Warner Losh wrote: >=20 >> I'd dispute the 'and surely it seems like it does' part of this. Non = x86 architectures will continue to use gcc because clang just isn't = ready at this time for them. Some are very close (arm), some are close = (powerpc64, mips*), some are no where near ready, or will never be ready = (sparc64, ia64). There's no coherent, documented plan for these absent = gcc at the moment. There are lots of pieces there, and those pieces will = form the basis of the solution (+handbook updates) for the removal of = gcc in 11, but we just aren't there yet. >=20 > The plan, which has been discussed on mailing lists, on IRC, and at = DevSummits is for tier 2 ports to depend on an external toolchain. For = those vendors that are not prevented from using GPLv3 compilers, this = means that they will be able to take advantage of, for example, the = significant improvements to the MIPS and PowerPC back ends that gcc has = had over the last 6 years. For everyone else, it will mean installing a = compiler from ports. That's the plan for FreeBSD 11, yes. For FreeBSD 10, gcc remains in the = tree. > For now, tier 2 architectures will continue to build a toolchain from = the src tree and use that. By 11.0, gcc will be gone from the base = system and they will be required to use something external if they are = not supported by clang. Brooks has been working hard on making this = easy, and it is generally an improvement for cross-building embedded = systems as the cross-compile toolchain is no longer rebuilt every time = you change a file in the kernel, resulting in faster builds. It is also = easier to use toolchains provided by chip vendors, which is something = that MIPS and ARM vendors have been asking for for a very long time. =20 Yes. Many of the building blocks are in place, but they haven't been = stitched together entirely yet. The 11 time frame is plenty of time to = tie up the loose ends and rough edges that are there, as well as to = ensure you can cross build a system, then do a native build on that = system with external toolchains... > For x86 and ARMv6/7, Clang has been the default compiler for a long = time and gcc has been increasingly problematic (for example, our gcc = does not support ARM EABI, which will be the default in 10.0 for ARMv6 = and later, so if you want to build for a modern ARM chip then you need = either clang or a more recent gcc than we ship). Claiming that this is = something done at the expense of non-x86 architectures is highly = misleading, as improving ARM support is one of the driving factors = behind the switch. I'm sorry, but that's not quite right. Our gcc *DOES* support arm EABI = with soft float. In fact, that's how we're using it now and how we're = using clang now as well. clang support for ARM is still shaky, even in = -current. EABI with hard float hasn't been done, and will require a = newer gcc and/or clang, but we're not entirely there yet. The fallback = for weird bugs is still "recompile with the in-tree gcc" and often that = has fixed issues that people hit either with clang, or with assumptions = about generated code that weren't quite true with clang and needed to be = fixed in our kernel. But *ALL* the other non-x86 architectures are significantly worse with = clang. ARM is marginally the same, but we're still some issues we're = fighting through with ports and such. I think I was clear about which = ones were affected, and how though in my note. > If you are shipping a product that relies on gcc, then for the 10.x = timeframe, you are free to build and use the gcc from the base system, = and the tinderboxes will prevent any non-optional components from being = modified in such a way that they can't build with this gcc. In the 11.x = timeframe, architectures that aren't supported by clang will need an = external toolchain. =20 Yup. And the external toolchain support will need to be well documented = and we need a cross building/installing external toolchain story that's = better. It works well enough to generate a system now, but not quite = well enough to generate a self-hosting system (which is required for the = ports cross-build-on-qemu solution). > AMD, Intel, AMD, Oracle, ARM, and MIPS are all actively contributing = to LLVM and Clang, so the only platform that is unlikely to have an LLVM = back end in the 11.0 timeframe is IA64, and if you really care about = IA64 then Intel will happily sell you a compiler that does a much better = job than GCC of targeting this architecture. Yes. I'm totally on board with that for the 11 time frame. 32-bit = powerpc had issues, and isn't in your list. Warner=