We're about to merge BFloat IR support , after discussions on Phabricator  and the mailing list . I think the responses have been quite positive towards this direction, but I would like to make sure we're also happy with what comes next.
We would need changes in both SelectionDAG and GlobalISel to support the BFloat type in the backend:
For SelectionDAG the changes are relatively straightforward. We'd need an MVT type for BFloat and for BFloat vectors, and we'd need changes in the various backends to support the new types. I've made a couple of patches to implement the MVT type and add support for AArch64. Together with general frontend support and ACLE intrinsics we can compile BFloat C code for AArch64.
For GlobalISel there's a bit more work to do. I'm not too knowledgeable about GlobalISel myself, but there was some discussion on this on another list thread  between the GlobalISel folks. The gist is that GlobalISel at the moment can't differentiate between different float types of the same bit-width. During the course of the list discussion it seems people were in favour of adding more type information to LLT to disambiguate floating point types.
Do we feel comfortable with this general direction for BFloat?
bfloat IR type: https://reviews.llvm.org/D78190
bfloat C type: https://reviews.llvm.org/D76077
mvt type: https://reviews.llvm.org/D79706
IR intrinsics support: https://reviews.llvm.org/D79707
add poly64_t on AArch32: https://reviews.llvm.org/D79711
neon emitter: https://reviews.llvm.org/D79708
basic bfloat support for AArch64: https://reviews.llvm.org/D79709
bfloat instr support for AArch64: https://reviews.llvm.org/D79712
get/set/dup intrinsics: https://reviews.llvm.org/D79710