JackAKirk

Looks good, do we want to also move these bfloat16 math functions out of experimental also: https://github.com/intel/llvm/blob/bdd88e50f0165e339f85c9b134d49972de079370/sycl/include/sycl/ext/oneapi/experimental/builtins.hpp#L160 since they are defined in the same extension document as the main bfloat16...

Also FYI there is another open PR updating the bfloat16 class that it might be good to consider merging first https://github.com/intel/llvm/pull/6492.

Example draft patch that incorporates new non-native software impls that pass tests for CUDA backend is here: https://github.com/rdeodhar/llvm/pull/1.

By the way, just in case you didn't notice, the [bfloat16_type.cpp](https://github.com/intel/llvm-test-suite/blob/intel/SYCL/BFloat16/bfloat16_type.cpp), is currently still marked xRUN on the CI for Intel (and also in my updated patch where I added...

Hi @dkhaldi If it is preferred for reviewing purposes I could add the temporary/initial fp19 implementation that uses uint32_t directly to this PR? Hopefully the uint32_t fp19 should be a...

> I think separate PRs is better. OK

/verify with https://github.com/intel/llvm-test-suite/pull/760

Same here: https://github.com/oneapi-src/SYCLomatic/pull/1181/files

> @JackAKirk the reference PR #1286 for sentence "The bfloat16 class has been non-experimental for a while now, supporting all backends" is incorrect, could you provide the correct PR? So...

> I think this could be OK. I'd like to consider merging the math functions into the base extension for bfloat16, though, rather than having two separate extensions. Sounds good...