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

[Friedman, Eli via llvm-dev]

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