karolherbst wrote: > > So we just don't want any mesa specific triple, because we really just want > > this to be treated as "application wants to compile OpenCL C" and any > > target specific information we want to deal with in our runtime, not at > > compile time. > > > Not really, but what we do is to parse SPIR-V and for builtins we want to > > use the libclc implementations (not all and it might depend on the > > hardware) we call into the parsed libclc SPIR-V functions instead. > > So we really just use it as a SPIR-V library and "link" to it at runtime > > selectively thought instead of actually linking function calls, we just > > link SPIR-V opcodes and the functions provided by the libclc SPIR-V binary. > > I think this is orthogonal to the PR, it just changes an internal build. > Though I could see that argument that it should default to > `spirv64-unknown-unknown` instead. >
Oh sure, I just don't think we should have a user exposed triple that mentions "mesa". I see the argument for an internal build, but even then I'd rather the focus would be to provide a uniform SPIR-V binary that all runtimes can use equally. > Personally, I think it would make sense to keep this as `mesa3d` just to > imply the graphics toolchain use. With my GPU compute hat on, this would just > be `clang --target=spirv64-mesa-mesa3d foo.cl` which implicitly links `-lclc` > via `-L /lib/spirv64-mesa-mesa3d`. Keeping denormals and others consistent is > more of a build problem and not explicitly related to the triple. But why would one want to link against `-lclc`? It really should just use the SPIR-V opcodes and OpenCL C extended instruction set, not call into libclc directly. And we for sure don't want anybody to do that. https://github.com/llvm/llvm-project/pull/199618 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
