[llvm-dev] [SPIR-V] SPIR-V in LLVM

[Hongbin Zheng via llvm-dev]

Hi,

I actively working on LLVM project with SPIR (no V here), and would love to
see SPIR-V get integrated into LLVM.

Does this SPIR-V "backend" support reading SPIR-V and generate LLVM IR
in-memory representation?



On Mon, May 1, 2017 at 6:44 PM, Nicholas Wilson via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

>
> > On 2 May 2017, at 8:48 am, Tom Stellard <tstellar at redhat.com> wrote:
> > You would probably need to write a new tablegen backend to generate
> > instruction tables that would be used outside of LLVM.
>
> I think I need to write one anyway because I need to generate lots of
> tables other than the instruction table (there are no registers and
> therefore no register table), at least one for each subsection of section 3
> of the spec and then some. Wether or not it is inside or outside of LLVM is
> irrelevant. What is, is that I’m not sure that the same can be said for
> intrinsics, which will enable the removal of the mangling hacks.


> >> I am in the process of trying to make it “more traditional” where
> possible and it makes sense to do so, but I do not fully understand the
> backend pipeline and am just trying to express the intrinsics and binary
> format with tablegen at the moment. Regardless of the actual transformation
> pipeline used I think it should go in target for the advantages stated
> above, and the one that I missed was, it has its own target triples! Also
> IIRC the Mill CPUs will/(do?) only use one or two of the backend passes and
> I can’t imagine them not being considered targets.
> >>
> >
> > A "more traditional" backend is more than just using tablegen to generate
> > the instruction definitions.  It means implementing an instruction
> selector
> > and using SelectionDAG and MachineInstrs.  What I'm saying is that
> > SPIR-V is not a good fit for the existing infrastructure, so I think
> > it would be good to consider alternatives before going to far down that
> path.
>
Not sure if the GlobalISel[1] allow us to skip some of the boring
ISelDAG/legalization things. In this case we maybe able to generate SPIR-V
from GlobalISel's generic Machine IR and by pass all those instruction
selection/legalization things?


>
> Indeed, tablegen is the first step. I intend to incorporate as much of the
> standard pipeline as makes sense (e.g. no register allocation because there
> are no registers). As I have said I know very little about the backend
> pipeline so I can’t comment a whole lot. Is SelectionDAG matching pieces of
> the IR and choosing instruction from them? Because I definitely want to do
> that, if it is a thing (the tablegen files are currently dag free and do
> not inherit from `Instruction` because I do not understand that process, I
> am merely transcribing the spec), any information is welcome.
>


>
> > I think we may be using different definitions of driver in this case.
> > From the perspective of LDC, it doesn't seem like it would matter
> > much if LLVM IR -> SPIR-V were in the LLVM tree or outside of it.
> > In both cases you have a library that takes LLVM IR as input and
> > produces SPIR-V as output.
> >
> > -Tom
>
> My point is that it is duplicated effort (i.e. one for LDC, one for clang
> and so on), and is redundant if it is a proper target. I am willing to put
> in the effort to allay concerns regarding the pipelining and legalisation,
> but I am steadfast in my opinion that it should be a target unless the
> benefits of not being a target can be shown to outweigh those of being a
> target.
>

Alternatively:
Since SPIR-V is very close to LLVM IR, it may be a bad idea to translate
LLVM IR to machine IR then to SPIR-V, direct LLVM IR/SPIR-V translation
maybe simpler.

In this case, we consider SPIR-V as an IO format instead of a backend. we
can introduce a special IR writer and IR reader that write SPIR-V from LLVM
IR in-memory representation and read SPIR-V to generated LLVM IR in-memory
representation. This is also not hard to integrate into clang/opt and I had
done similar things (not SPIR-V though)

In this case, it will be opt that read and generate SPIR-V, instead of llc.
This allow us to read SPIR-V into the pass pipeline and optimize them.

Thanks
Hongbin

 [1]http://llvm.org/docs/GlobalISel.html

>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170502/a72e77cd/attachment.html>