JonChesterfield wrote: > I'm not convinced we should do this, as I have a bunch of concerns: > > * it's intrusive and duplicates work already done by > [libclc](https://github.com/llvm/llvm-project/tree/main/libclc);
Also compiler-rt. Also gpuintrin.h. Also openmp's devicertl. All the language runtimes duplicate this work because it's necessary to program the GPUs. Or we put it in LLVM and they all get to use the common layer. > * [SPIRV already has > intrinsics](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/IR/IntrinsicsSPIRV.td) Quoting from that file: // The following intrinsic(s) are mirrored from IntrinsicsDirectX.td for HLSL support. Also amdgpu has intrinsics. And so does nvptx. And so does opencl. Do we really want one intrinsic per language for a concept like thread_id? > * it squats on some prime naming real estate I don't care about names. If llvm.gpu wants to be reserved for something else, llvm.simt or llvm.gpuintrin or whatever are absolutely fine by me. > * it is extremely chunky The lowering is 500 lines written with no effort to be concise to cover both architectures. Twenty of so of tablegen. Almost all this patch is test code and the proof of concept in gpuintrin. > * not everything should end up in Clang, even though it is individually > "convenient" It's the LLVM IR I'm after here. The auto-generated clang builtin to expose the IR directly to language runtimes seems fine, but I can get by with a handwritten IR file and a C header if that turns out to be a blocker. > I am equally uneasy with the cavalier attitude towards differences between > various GPU and GPU-like targets. This abstraction is pre-existing. I've deliberately chosen the pre-existing one which is known to work well enough to drive libc, which is also just about enough to cover openmp. Where people don't want to abstract over the architecture they have a wide variety of existing choices. 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
