Date: Sat, 24 Aug 2013 09:42:02 -0600 From: Warner Losh <imp@bsdimp.com> To: David Chisnall <theraven@freebsd.org> Cc: toolchain@freebsd.org, John-Mark Gurney <jmg@funkthat.com>, Alfred Perlstein <alfred@freebsd.org>, "re@FreeBSD.org Engineering Team" <re@freebsd.org>, current@freebsd.org Subject: Re: patch to add AES intrinsics to gcc Message-ID: <8C31A000-6806-4291-98A4-E8291E637BD2@bsdimp.com> In-Reply-To: <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <105E26EE-8471-49D3-AB57-FBE2779CF8D0@FreeBSD.org> <CAE-m3X324rbdP_C=az4eO-EkMcR-yFAeRG7S4q%2BMUsnMezGddw@mail.gmail.com> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 24, 2013, at 4:05 AM, David Chisnall wrote: > On 23 Aug 2013, at 23:37, Warner Losh <imp@bsdimp.com> 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8C31A000-6806-4291-98A4-E8291E637BD2>