Re: patch to add AES intrinsics to gcc

On Aug 24, 2013, at 4:05 AM, David Chisnall wrote:

> 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.

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.  

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.  

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