[clang] [llvm] [SPIRV] GPU intrinsics (PR #131190)

[Jon Chesterfield via llvm-commits]

================
@@ -0,0 +1,501 @@
+//===- LowerGPUIntrinsic.cpp ----------------------------------------------===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+//
+// Lower the llvm.gpu intrinsics to target specific code sequences.
+// Can be called from clang if building for a specific GPU or from the backend
+// as part of a SPIRV lowering pipeline. Initial pass can lower to amdgcn or
----------------
JonChesterfield wrote:

As in the commit message, I want spirv to be usable as a target agnostic representation for gpu compute. https://discourse.llvm.org/t/rfc-spirv-ir-as-a-vendor-agnostic-gpu-representation/85115. Pretty much all it needs for that is a way to talk about simt intrinsics and a lowering to the vendor.

I think it is _deeply_ silly to have lots of intrinsics named after languages which mean the same thing and want to fold them together into the llvm core. So far I'm not getting a lot of love for that but I concede that sweeping cleanup isn't strictly necessary, being technically much cleaner doesn't always means politically tractable.

The builtins and intrinsics introduced here are target agnostic. I think people would be much happier if I'd named them llvm.spirv or llvm.openmp but given they have nothing to do with spirv or openmp, aside from being useful for both, I'm arguing against that.

Spir64-unknown-unknown doesn't say anything about amdgpu or nvptx or intel. Nor should it. It really doesn't say much about the GPU architecture. That's why it's viable as a target to JIT into amdgpu or nvptx later. That's the goal of spirv64, right? Single shader IR that runs on arbitrary GPUs?

I don't particularly care how these intrinsics are represented in SPV, provided they can be raised back onto these llvm intrinsics in the translator. The name llvm is appropriate as that's where the semantics for these intrinsics is defined. I don't know what distinction you're drawing between abstract function calls and intrinsics, terminology is not consistent across compilers here.

https://github.com/llvm/llvm-project/pull/131190