Hi all, We're about to merge BFloat IR support [1], after discussions on Phabricator [2] and the mailing list [3]. 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 [4] 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? relevant patches: 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 Thanks, /Ties Stuij [1] https://reviews.llvm.org/D78190 [2] https://reviews.llvm.org/D76077 [3] http://lists.llvm.org/pipermail/cfe-dev/2020-March/064948.html [4] http://lists.llvm.org/pipermail/llvm-dev/2020-May/141405.html