[PATCH] D123693: Transform illegal intrinsics to V_ILLEGAL

Jay Foad via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Aug 1 06:32:58 PDT 2022


foad added a comment.

In D123693#3581616 <https://reviews.llvm.org/D123693#3581616>, @bcahoon wrote:

> The rationale is for library code that looks like:
>
>   void example(float *p, float v) {
>     if (_ISA_verison == 9008 || __ISA_verison == 9010)
>        global_atomic_fadd(p, v);
>     else
>        generic_atomic_fadd(p, v);
>   }
>
> At optimization levels > 0, the dead code is eliminated, but at optimization level 0, the dead code remain and the compiler attempts to generate an instruction. That instruction would never be executed due to the condition, but it still needs to be generated. In these cases, we don't have multilibs (target specific libraries).

Right, but why can't `global_atomic_fadd` and `generic_atomic_fadd` be functions that just contain a call to the corresponding builtin and have an appropriate "target-cpu"= attribute? I guess you would need to do inlining in the backend once you know what subtarget you are compiling for. Is that viable?



================
Comment at: llvm/test/CodeGen/AMDGPU/v_illegal-atomics.ll:1
+; RUN: llc -march=amdgcn -mcpu=gfx906 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX906 %s
+; RUN: llc -march=amdgcn -mcpu=gfx908 -verify-machineinstrs < %s | FileCheck -check-prefixes=GFX908 %s
----------------
File should not be executable.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D123693



More information about the llvm-commits mailing list