Date: Sat, 24 Aug 2013 11:05:15 +0100 From: David Chisnall <theraven@freebsd.org> To: Warner Losh <imp@bsdimp.com> 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: <1380949A-254A-4222-BEDE-0C23E16E4F67@freebsd.org> In-Reply-To: <86032E72-A569-4946-B4F8-26F687067B31@bsdimp.com> 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>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 23 Aug 2013, at 23:37, Warner Losh <imp@bsdimp.com> wrote: > 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. 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. 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. 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. 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. 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. David [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) Comment: GPGTools - http://gpgtools.org iQIcBAEBAgAGBQJSGIVbAAoJEKx65DEEsqId0egQAMvbN7D098fi3SlVoIPiiQFA 28ZZuzTOTFqN/Oa8J91TmpQXBCF08D5S0zVYU1lTCzdvb8YpL++uTCvcaa3C5/19 xsSX0Z67JPq72PTIt3uWAjzDbYWAkZI8KugCQAxhlrI+eYFQ4MvqUPT084+FlzN6 3pRZ00npFz51DSME2/kJoTu50QkdAhACij1bcNcndGRns4Z0HgbNPGuIJnx0/Ix8 3ZuxiCOCrtvWCHQfrJWA51vroY+z6vHKpylX+IvFqyI6XJNI4lIViGD0r1fikkq7 DD33jL3qC7Yc6cJchJfmd8iURWJOztNn1rydukoFjXR86kmja4ekeG9JxIGiQidQ uGE4VPtTltUwv7d1UI+XTEQSLi02hqoVbW6oUHVp30Kw5uGaRKt9H9xtIz+3U+l9 gRiSBd8fxn2yhpqHTsGsQ2p5EYpKP0TOEIeWCmuA51V/dciUEwRG3dMF6goXoM42 yjoeWd9m234YDFRq1HPr/0RzuTMXb8YN3S+2IpBXOL8PRXZk6RyR0P8AncH62Bgs ld4P0Z5DkJ1R0DgnR4AYZAp04rfSWiCmVdvKXp+YFTlNfn484WVWKOUlQZCizCsb TDAVg4cEkV4bwsZguCmgwahyJ5LDxiLBZ3Ouph6dOSYK4TThtNhdYR3pAzIofSLV o+2fKlJOcZeiCK6CmDFt =09Fb -----END PGP SIGNATURE-----help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1380949A-254A-4222-BEDE-0C23E16E4F67>