jhuber6 wrote: > I think there is a misunderstanding. We don't need fma implemented as a > software fma. > > We need an exported function that we can use for devices that do not have > native fma. > > Inside mesa we have logic to control whether `OpFmaKHR` or the `Fma` OpenCL > extended instruction is implemented as a native hardware instruction or > emulated in software. > > It's fine for the SPIR-V binary to end up with those opcodes. What is the > problem is, that the software implementation isn't available inside the > SPIR-V anymore.
Shouldn't lowering FMA properly be the backend's job? I'm curious why we cannot simply call a single FMA function and have the target decide if it can be implemented natively or in software. https://godbolt.org/z/5qodxY3vM https://github.com/llvm/llvm-project/pull/199626 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
