karolherbst 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
Yes, we have our own compiler backend in Mesa and that's why just seeing any `fma` opcode in the final SPIR-V is fine. We just need a fallback software implementation of fma provided in some form. Either as a helper function inside the libclc SPIR-V binary or something else. If upstream LLVM decides that only OpenCL C builtins are provided, then that's a decision I could accept, it just means I'd have to add a software fma implementation to mesa even though one already exists technically in libclc and I'd rather just skip the work. But if that's how we all want this to work in the future, so be it. And I'd rather not choose "all fma is implemented as software now, because that's the only thing we want to provide, because libclc is really no project that would provide helper functions". https://github.com/llvm/llvm-project/pull/199626 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
