[llvm-dev] [SPIR-V] SPIR-V in LLVM
Nicholas Wilson via llvm-dev
llvm-dev at lists.llvm.org
Wed May 3 21:20:07 PDT 2017
>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
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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev