jhuber6 wrote:

> > spirv*-mesa-mesa3d are legal clang targets since 
> > [3c6fe49](https://github.com/llvm/llvm-project/commit/3c6fe49a912adc1ffe174bdf3d547a8bd6826bee).
> 
> Please revert this or rename it to `spirv*--` to indicate it's a generic 
> triple not tied to any implementation. We don't want any mesa specific 
> triples or any implication that mesa is in any capacity a special target 
> within clang.
> 
> I don't understand why we are now adding the concept of triples to SPIR-V and 
> GPU runtimes. And I really really really don't want that we imply in any way 
> that applications would need to provide their OpenCL runtime specific SPIR-V 
> binaries. Please make no assumptions about how FMA is implemented, no 
> assumptions about denorm behavior or anything, because we'll have to support 
> the same spirv across varies hardware that have different implementation 
> details.
> 
> And developers using clang to compile OpenCL C to SPIR-V should simply target 
> OpenCL SPIR-V and nothing else. And use the same binary for every runtime.
> 
> We consume OpenCL/Vulkan SPIR-V. Not "mesa" SPIR-V. And we certainly don't 
> want clang/llvm to apply any assumptions how our runtime behaves or requires 
> beyond Extensions and Core language features.

Could you elaborate on this a bit more. Using `spirv64-unknown-unknown` still 
works as far as I am aware. Most of this has been to bring `libclc` into the 
more general `clang` handling where libraries are sorted by triples. The triple 
is just a toolchain selector, it's how you tell the runtime to compile for 
SPIR-V in the first place. In libclc we have triples for `amdgcn`, `nvptx`, and 
`spir-v` so I don't really understand why SPIR-V is special here. We already 
differentiate between two flavors for SPIR-V, one for the "Vulkan" CLSPV 
project and the other for the 'standard' SPIR-V behavior. 

The compiler mostly cares about toolchains, so it knows where to find what 
libraries. To me, this isn't any different from `x86-64-unknown-linux-gnu` and 
`x64-unknown-linux-musl` both producing the same ISA in an ELF. What's special 
about SPIR-V? I am not that familiar with the Khronos approach to things.

https://github.com/llvm/llvm-project/pull/199618
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to