[LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

[Liu, Yaxun (Sam)]

Sorry for my late reply. 

Thanks for sharing your concerns. I commented about some technical concerns below. For the concerns about the ownership and long-term maintenance, I will bring them back to the SPIR WG. Hopefully we will come back with a satisfying solution.

Sam
-----Original Message-----
From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames
Sent: Friday, May 22, 2015 12:29 PM
To: Neil Henning; llvmdev at cs.uiuc.edu
Subject: Re: [LLVMdev] [RFC] Upstreaming LLVM/SPIR-V converter

On 05/22/2015 03:55 AM, Neil Henning wrote:
> 'Maintenance and support obligations' - the only maintenance 
> obligations would be don't regress our tests when you change code, 
> that is no different from doing changes to any other target.
I think SPIR as discussed is different in two potentially important ways:
- The lack of target information.  Can we even run IR passes over SPIR derived IR and get back valid SPIR?  This hasn't been resolved.
	+ My understanding is that SPIR-V targets generic OpenCL/GL devices and assumes a common natural data layout. Optimizations allowed on SPIR-V should not introduce any target specific dependence. The common use case of SPIR-V is that a vendor generates SPIR-V with minor optimizations and sends it to a user. The user translates SPIR-V to LLVM and performs target-specific optimizations and codegen, and executes the ISA.
- SPIR has explicit compatibility provisions across versions. Adding a bi-directional converter makes the community responsible for preserving this compatibility, even in face of otherwise breaking IR changes.  I haven't seen this clearly discussed yet.
	+ The current implementation of LLVM to SPIR-V converter works by breaking down the IR to instructions and constructing the corresponding entities in SPIR-V. The SPIR-V to LLVM converter works the other way around. Their dependence on the IR is mainly on the API for getting information about entities and creating entities in the IR. The dependence is not much different from other LLVM module passes. I have seen porting efforts of the converter among LLVM 3.2/3.4/3.6, which are no more difficult than typical LLVM module passes. For example, the main porting efforts from 3.4 to 3.6 is the change in API changes about metadata and user iterator, which are quite straightforward.