karolherbst wrote: > > 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. > > That's the current behavior, no? Last I checked only the OpenCL public names > are exported? Are you not emitting calls to the various itanium mangled > flavors of `fma`?
Okay, seems like I was a bit confused how this PR changes things and the layers of indirection that are currently there. Looking at the binary more deeply I'm seeing: - `fma` implemented as calls to `__clc_sw_fma` - `__clc_fma` functions implemented as `OpFmaKHR` - `__clc_sw_fma` having the software implementation. - builtins (e.g. `__clc_erfcf`) seem to call into `__clc_fma`, which is just `OpFmaKHR`. So if I'm not mistaken, any builtin implementation goes through `OpFmaKHR` directly or indirectly. So that would work. With the only caveat that older runtimes won't be able to consume `OpFmaKHR` because that's an optional SPIR-V feature, but that's another issue. Initially I read it as builtins would call into `__clc_sw_fma`, which wouldn't have been okay as the thing we are intercepting are SPIR-V opcodes, not function calls. https://github.com/llvm/llvm-project/pull/199626 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
