Re: patch to add AES intrinsics to gcc

On 23 Aug 2013, at 23:37, Warner Losh <imp_at_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