[llvm-dev] [cfe-dev] [RfC] A proposal of adding SPIR-V Toolchain in Clang (original) (raw)

Friedman, Eli via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 12 11:20:51 PDT 2018

On 9/11/2018 7:43 PM, Tom Stellard wrote:

On 09/11/2018 12:31 PM, Friedman, Eli via llvm-dev wrote:

On 9/10/2018 8:10 AM, Anastasia Stulova via cfe-dev wrote:

This will result in the following Clang actions:

(1) clang -cc1 -triple spirv[32|64]-unknown-unknown test.cl -emit-llvm-bc -o test.bc (2) llvm-spirv test.bc -o test.spv Even if llvm-spirv is technically a separate binary, it's still tightly coupled to the clang version because the bitcode format changes over time; it would be a support nightmare if clang shipped by llvm.org passes bitcode to some binary which isn't shipped by llvm.org. Are you concerned about the support burden for the LLVM maintainers or the llvm-spirv maintainers?

When someone runs into an issue with a clang shipped by llvm.org and an llvm-spirv shipped by someone else, I would guess they'll basically choose randomly whether to blame clang or the llvm-spirv tool.

Thinking about it a bit more, maybe the issue isn't unsolvable... if we make sure to specifically only invoke llvm-spirv installed beside clang (so we aren't grabbing a random binary from the PATH), and binary releases of llvm-spirv project ship a complete sysroot so people are never directed to mix llvm-spirv releases and llvm.org releases, and we print high-quality error messages if llvm-spirv is missing or mismatches, it's probably not too confusing.

I'm still not really happy that we can't manage to integrate a SPIR-V backend into LLVM instead, but I guess if that changes in the future it would be mostly transparent to users.

-Eli

-- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project

More information about the llvm-dev mailing list