> 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.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. > > -TomMy 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.
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>
On 05/01/2017 09:44 PM, Nicholas Wilson 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. > > 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. >Right, what I was trying to say is that there are more benefits from having this not be a target than there is from having it be a target. What you are proposing is a lot of work, and even if it does help to avoid some duplicate work (which to be honest, I still don't quite understand what duplication there would be if it weren't a target), I don't think that is enough to justify the effort required. -Tom
>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?Yes it does.>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.Having a look through the GlobalISel page makes me think the same, at least without looking at how web assembly/NVPTX deal with register banks.>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.That sounds like a good idea, except that it would have to be a target I/O hybrid because an I/O format having its own intrinsics I think is even weirder than a target that doesn’t use ISel/MC (all of the previous points about reasons for being a target still stand). Though a target I/O hybrid is pretty weird. A target for the forward compilation, I/O for reverse? Also take a look at llvm-spirv [1], which does the interconversions, well delegates the interconversions to the library. The only problem for opt would be the target triple, i.e. want to output for AMDGPU need the triple to be correct and then also translate all the intrinsics over. Perhaps for the reverse i.e. consumption of SPIR-V, something like libclc[2] would be the way to go (and an equivalent for Vulkan)? It is also worth noting that all these same quandaries would apply if/when MS decide to upstream their DXIL, since it is effective the same thing but different. [1]:https://github.com/thewilsonator/llvm-tool-spirv [2]:http://libclc.llvm.org<http://libclc.llvm.org/> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170503/a009e1e1/attachment.html>
>Right, what I was trying to say is that there are more benefits from>having this not be a target than there is from having it be a target.Please enumerate them, I have seen none posted so far . The implied “it is what all the the other backends do” w.r.t ISel/MC is at best(worst?) an implementation detail, and I’m still not quite sure why Chandler was so adamant about that. He seemed to imply that generating straight from the IR (as opposed to post legalisation?) introduces a direct dependance in the IR that the rest of LLVM would then be required to not break? I agree that the SPIRV backend should be insulated from changes the IR, although I’m not sure how to achieve that property. I’m also not sure how much, if at all, it would be susceptible to that to begin with. Deletions of instructions/attributes would obviously cause breakage and additions may cause unhandled and/or invalid combinations. I still don’t get the severity if this though, insight appreciated.>What you are proposing is a lot of work, and even if it does help to >avoid some duplicate work (which to be honest, I still don't quite >understand what duplication there would be if it weren't a target), >I don't think that is enough to justify the effort required.My point is that (modulo metadata, which I am still investigating better alternatives, and calling conventions) if SPIRV is a target, then a producer need not change their compilation pipeline at all to target SPIRV. There should be no effort required, it would come as a property of being a target. I think we are confusing each other again :( Leaving that aside for a moment, there are a number of advantages/requirements that, correct me if I’m wrong, would be impossible without a proper target. * Most critically: Intrinsics. I am almost certain that you would not accept the current mangling hacks, and if I am to support windows neither can I. Any solution would therefore need to be able to register intrinsics and I believe this is impossible without a target (and even if it is, it makes less sense than a target that doesn’t use ISel/MC). Not being able to use intrinsics is a complete deal breaker. *Basic optimisations (basic CSE,DCE,inlining): requires a TargetLibraryInfoImpl(?) which I believe requires a target. While not strictly necessary it would improve the readability of the resulting IR/SPIRV. All of the more complex optimisations would be done “post ingestion” of the SPIRV and with a different target triple so are unaffected by any decision made. See my reply to Hongbin for an approach. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170503/d26ad405/attachment.html>