karolherbst wrote: > > The input is generic OpenCL SPIR-V. There is nothing mesa specific about > > it, but I think it's not a good idea to imply otherwise. > > This is mostly just questioning how things are build in mesa. Because if you > ever wanted to have custom toolchain handling for building mesa-compatible > objects you would want a dedicated triple for it (e.g. > `x86_64-unknown-linux-gnu` vs. `x86_64-unknown-linux-musl`). But I would > assume that you are hard-coding tool invocations in mesa rather than running > it through clang (I would guess because clang cannot consume SPIR-V yet). > > I know the mesa component completely changes the ABI in the `amdgcn` step, so > mostly this was an assumption that you'd go from mesa SPIR-V to mesa AMDGCN > or similar when compiling. > > Realistically this PR is all documentation though, I think it's just up to > the user as the unknown variant still worked.
Again: the input is generic OpenCL SPIR-V. There is nothing mesa specific about it. And we do not expose any mesa specific formats to anything outside of Mesa. Really, the transport binary format for anything OpenCL specific is generic OpenCL SPIR-V and we have no plans to ever change that. We have our own compiler which doesn't use LLVM, except for translating OpenCL C to generic OpenCL SPIR-V via `clang`. But then the input is generic OpenCL SPIR-V again. Really, there is no need for a mesa specific triple and there will most likely never be one. And I'm getting tired of explaining it over and over again, so please don't make this more difficult than it needs to be. https://github.com/llvm/llvm-project/pull/199618 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
