[PATCH] Teach the AArch64 backend about half-precision floating point

[Oliver Stannard]

> Then there's the promotion. I think that's rather more problematic. In general trunc . OP32 . extend != OP16. Apparently, it *does* work for add, sub, div, mul & sqrt, but explicitly not for fma. Personally, I'd be extremely surprised if it worked for the transcendental functions, but I haven't tried to prove it.

My original intention when adding the promotion was to make the backend capable of handling any operation that can be expressed by IR, so that it could be robust against optimisations introducing half-precision operations. However, if this could give the wrong results, I agree it would be better to fail the compilation.

Would it be OK to simply remove all of the promotions to f32, leaving them to fail at instruction selection, or is there a better way to express that an operation is not supported?

Should I leave the promotions in for add, sub, div, mul & sqrt, or do you think it would it be better to be consistent?

> So we want to be very careful in that area. If we really want to support half as a native type, we'll probably need to add libcalls for some operations.

I'm not currently aware of any source language other than opencl which allows operations on the half type (ACLE promotes to float first), so adding libcalls seems like overkill at the moment.

http://reviews.llvm.org/D4879