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

[Nicholas Wilson via llvm-dev]

>So there are really two questions here:

>1. Should targets be required to use SelectionDAG/GlobalISEL ?
>2. Should SPIR-V use SelectionDAG/GlobalISel?
>
>In my opinion, regardless of the answer to question #1, the answer
>to question #2 is no, SPIR-V should not use SelectionDAG/GlobalISel.

Yes I have come the same conclusion when I saw how much type information was lost.

>I touched on this before in previous emails, but the main problem is that
>SelectionDAG (and GlobalISel to a lesser extent) plus the whole MachineInstr
>layer is a much lower-level representation than SPIR-V, so you will
>need to do a lot of extra work and/or modifications to existing
>infrastructure in order to get a working target, and even then
>you may be limited to emitting poor quality SPIR-V that other
>backends will have a hard time optimizing.
>
>With all this work, what advantages are you getting?  If the
>only reason to do it this way is so you can use intrinsics,
>or TargetLibraryInfo, or easier integration with other tools,
>I think it would be better to try to save the effort and try
>to solve those problems in some other way.

I didn't really want to do that in the first place, but your responses and Chandler's
reply in the previous RFC made it seem an absolute requirement.

>LLVM IR -> SPIR-V directly will give you better code, lower compile
>times.  It will be more simple and easier to maintain, and you will
>be able to re-use existing SPIR-V parsers/writers that exist
>in SPIRV-Tools.

Yes the current approach seems to be the place that has the most type info.
(aside the AST of the producer, but that is a non sequitur, because what
would we be building a backend for?).
The parser and writer already exist in the code base, as do the
interconversions between LLVM <->SPIR-V, so the only use would
be for the verifier for testing. I mean I could replace them, but that
is effort for nothing

>This goes back to something I mentioned in my original email, but
>I really think the best thing to do for this project right now is to
>keep it separate from LLVM, clean up the code, and try to get people
>using it.  It's going to be much easier to get this upstream  in LLVM or
>even convince people that the answer to question #1 should be 'no' if we
>have a code base that is mature, well supported, and has a healthy
>userbase.

The purpose of this thread is to notify the community that I am working  on
this so that there ends up only one proposal and we don't waste effort.

I'll  definitely  polish and test thoroughly once I get intrinsics and the rest of
the tablegen stuff done.
I hope to get a large user base but this is sort of chicken and egg.
Keeping it separate is not a viable longterm solution and is the primary reason
why I want to upstream it eventually.

>You don't need to register intrinsics to be able to use them, and
>it's also possible to register them without a backend, but this has not
>been done before.

"Hasn't been bone" in an encouraging way, or not?
And you base them on what, the collection of triples?
(i.e. spirv: 32-bit OpenCL, spirv64: 64-bit OpenCL and possibly  a Vulkan one
if/when I have an idea on what to do with the (lack of) layout)

Irrespectively my fork will stay a target for now.

>You don't need a target for this.  TargeLibraryInfo is constructed
>based on the triple.

Ah, OK, maybe it was that there wasn't a triple independent one available
for the really simple operations when I was trying to enable it.

Thanks,
Nic

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170504/244c3f95/attachment.html>