[PATCH] D85911: libclc: spirv: Add various functions

Jan Vesely via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 1 10:55:57 PDT 2020


jvesely added a comment.

In D85911#2247585 <https://reviews.llvm.org/D85911#2247585>, @jenatali wrote:

> In D85911#2247580 <https://reviews.llvm.org/D85911#2247580>, @jvesely wrote:
>
>> I understand the mechanism you're aiming for. It' not clear whether the absence of fp64 path is intentional or not. afaik, all hw exposing fp64 also implements `fma.fp64` in hw so generic clc implementation works.
>
> Agreed, I expect all fp64 hardware has a native fp64 fma. However, for hardware-native implementations of CL functionality, we don't need a libclc function which maps to an LLVM intrinsic, because the SPIRV-LLVM-Translator maps calls to `fma()` to a SPIR-V opcode -- regardless of whether that `fma()` has an implementation present in the module. In fact, we *can't* have functions which map to LLVM intrinsics, because the SPIRV-LLVM-Translator will *fail* to map that to SPIR-V at all -- it doesn't map to the SPIR-V opcode.
>
>> resuing the generic clc `fma.cl` still works to expose the knob for fma.fp32 added in `D85910`
>
> It does not, because that results in code which calls the LLVM intrinsic, which fails to translate to SPIR-V.

so the translator can translate calls to `fma`, but not call to `llvm.fma`? that's weird. Please add that in a comment. Otherwise LGTM.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D85911/new/

https://reviews.llvm.org/D85911



More information about the llvm-commits mailing list