================ @@ -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 ---------------- michalpaszkowski wrote:
I would like to better understand your goal here with this patch and potential future patches. How is this written in terms of the spirv64 triple? What is specific about the intrinsics that they only "work" for SPIR-V triple or the other way around? The SPIR-V triple in a module does describe characteristics about the module and obviously the architecture -- including a calling convention, vendor, address spaces, environment, etc. and most importantly indicates the target used -- in this case the in-tree SPIR-V backend. However, I do not see how the SPIR-V triple in case of this patch is relevant to the SPIR-V backend. If the goal is to define new intrinsics which could be handled by AMDGPU and NVPTX, then I don't think those should be associated with the SPIR-V triple in LLVM. Is your goal to have SPIR-V backend implement these intrinsics (lower into proper spec defined SPIR-V builtin calls or primitive instructions)? Or would you see the backend just keep these as function calls? If the latter, then I am not sure this is the right use of `llvm.` intrinicis [according to the guidelines](https://llvm.org/docs/ExtendingLLVM.html#adding-a-new-intrinsic-function)? In theory, I would expect all `llvm.` intrinsics to be handled by the backends. Having SPIR-V backend emit abstract function calls for intrinsics which could be lowered into the SPIR-V spec defined instructions or builtins is a very dangerous path and opposes the idea of the SPIR-V spec altogether. https://github.com/llvm/llvm-project/pull/131190 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
