[llvm-dev] [RFC] Upstreaming a proper SPIR-V backend

[Trifunovic, Konrad via llvm-dev]

Answering to Renato's points:

> I think there are two points here:
> 
> 1. How many SPIRV end-points we have

I would rather call this 'two entry points', as to having two entry points for accessing SPIR-V: either through LLVM-IR with augmentation (metadata/intrinsics), or, a proper MLIR 'SPV' dialect.
 
> This is mostly about software engineering concerns of duplication, maintenance, etc. But it's also about IR support, with MLIR having an upper hand here because of the existing implementation and its inherent flexibility with dialects.
> 
> It's perfectly fine to have two back-ends for a while, but since we moved MLIR to the monorepo, we need to treat it as part of the LLVM family, not a side project. 

Agreed. We are not treating MLIR as a side project 😊 

> 
> LLVM IR has some "flexibility" through intrinsics, which we could use to translate MLIR concepts that can't be represented in LLVM IR for the purpose of lowering only. Optimisations on these intrinsics would bring the usual problems.
> 
> 2. Where do the optimisations happen in code lowering to SPIRV
> 
> I think Ronan's points are a good basis for keeping that in MLIR, at least for the current code. Now, if that precludes optimising in LLVM IR, than this could be a conflict with this proposal.

I think You are referring to points made by Lei, not by Ronan 😉
I believe that the idea of MLIR path is to completely skip LLVM-IR optimization passes, so having just the MLIR 'entry point' would preclude that possibility. (though, it would be possible to do FE -> LLVM-IR (optimize here) -> LLVM-IR to MLIR -> MLIR to 'spv' MLIR dialect -> SPIR-V, but that seems like an overkill...)
 
> If the code passes through MLIR or not will be a decision of the toolchain, that will pick the best path for each workload. This allows us to have concurrent approaches in tree, but also makes it hard to test and creates corner cases that are hard to test.

If we provide two 'entry points' for accessing SPIR-V, it is up to the toolchain to decide the most convenient way. I'm not sure whether this would be a runtime decision though. I believe that all future front-ends would like to target MLIR directly (and skip LLVM-IR altogether).
 
> So, while I appreciate this is a large proposal, that will likely take a year or more to get into shape, I think the ultimate goal (after the current proposal) should be that we end up with one back-end.

Agree. Though I would say : one back-end, but two 'entry points'. As I wrote in a reply to Mehdi, it seems that an option of having 'LLVM IR backend' produce 'spv' MLIR dialect would be a good way to ultimately unify the implementation. Though, that seems like a longer distance and needs some research, since, at the moment I'm not sure how to tackle this (to have GlobalISel produce MLIR as an output).
 
> I'm a big fan of MLIR, and I think we should keep developing the SPIRV dialect and possibly this could be the entry point of all SPIRV toolchains. 

MLIR should be an entry point for all future SPIRV toolchains - that is the future. There will be still toolchains that are legacy and cannot be rewritten to use MLIR.

 
> While Clang will take a long time (if ever) to generate MLIR for C/C++, it could very well generate MLIR for non-C++ (OpenCL, OpenMP, SYCL, etc) which is then optimised, compiled into LLVM IR and linked to the main module (or not, for multi-targets) after high-level optimisations.

I'm not sure about Clang OpenCL support. I believe that OpenCL C/C++ cannot produce MLIR directly. For OpenMP, I know that flang (Fortran) does have a MLIR based 'codegen'. Not sure about SYCL either. Someone from Intel should know? Does clang based SYCL compiler have a path to produce MLIR?
 
> This would answer both questions above and create a pipeline that is consistent, easier to test and with lower overall maintenance costs.

We should definitely aim at SPIR-V support to be less fragmented if possible (at the moment, we also have SPIR-V <-> LLVM bidirectional translator which is an external project).

> cheers,
> --renato