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

[Renato Golin via llvm-dev]

On Wed, 3 Mar 2021 at 10:11, Trifunovic, Konrad <konrad.trifunovic at intel.com>
wrote:

> > With that said, I understand that software development has many reality
> concerns (like existing codebase, familiarity with different components,
> etc.) and we have many different use cases, which may mean that different
> paths make sense. So please don't take this as a negative feedback in
> general. It's just that to me it's unclear how we can unify here right now.
> Even when the time arrives for unification, I'd believe going through MLIR
> is better to have general SPIR-V support. :)
>
> A very good discussion! I seem to be overly optimistic at the first place
> at unifying those two approaches. Now I believe that we actually should
> have two paths, for the reasons You have just explained and for the reasons
> of supporting 'legacy' paths/compilers that rely on a classical, years old
> approach: Front-End -> LLVM-IR (opt) -> backend (llc). For that legacy
> path, a plain old 'backend' approach is still (in my view) the way to go.
> On the other hand, when MLIR evolves and gets wider adoption, it will be
> the way to go. From the semantic point of view, MLIR is much better suited
> for representing structured and extensible nature of SPIR-V. But for MLIR
> approach to be adopted, new languages/front-ends need to be aware of that
> structure, so to take most of the advantage of it. If Clang C/C++ start to
> use MLIR as its native generation format - that would be a big case for
> MLIR approach, but until that happens, we need to have some intermediate
> solution.


I think there are two points here:

1. How many SPIRV end-points we have

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.

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.

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.

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.

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.

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.

This would answer both questions above and create a pipeline that is
consistent, easier to test and with lower overall maintenance costs.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210303/30a4f79e/attachment.html>