Totally agree Philip! I think the main pending issue is are we allowed to have a target that doesn't go through the normal mechanisms that targets adhere to - and is basically just a ModulePass underneath. In light of how thorny this request has been perceived in the past, I'd honestly rather just make external targets work _without_ patching LLVM being a requirement, and then any SPIR-V target (or any other external LLVM targets too!) can live, mature, and prove its usefulness while there is an avenue to use vanilla tip LLVM with the SPIR-V target and go through the normal mechanisms. Cheers, -Codeplay Neil. On 2017-05-10 03:52, Philip Reames via llvm-dev wrote:> On 05/08/2017 10:31 AM, Friedman, Eli via llvm-dev wrote: >> On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: >>> On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>>>> 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. >>>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >>> 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. >>> >> This is completely skipping over one very important step which is >> currently part of ISel: legalization. The LLVM optimizers expect >> backends to support arbitrary-width integers, arbitrary-width vectors, >> and target-independent intrinsics which are lowered by legalization. >> SPIR-V does not have native support for these, therefore you need the >> legalization framework. And the legalization framework in LLVM is >> fundamentally tied to ISel. > I'll just add a non-technical point here. Beyond the technical merits > of "being a target" vs "not being a target" (which I will admit I've > mostly skipped in this thread because it appears to be repeating > previously discussed material), there is a *much* lower barrier to > entry for "being a target". We have standards in place for new > targets; we're use to thinking about new targets. If you want to add > something fundamentally new, that will require a lot more design buy > in and will have to clear a higher bar (in practice.) Given I see > little evidence of such buy-in to date, pursuing a "not a target > strategy" will be substantially more risky. > > Philip > > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
At least in principle LLVM is designed to have Targets that are not based on lib/CodeGen. Looking at the APIs it should be possible to just implement TargetMachine (but not LLVMTargetMachine which is only meant for lib/CodeGen targets) and register that with the target registry. Note that I have never actually done so, so I may be missing some things. It also seems the last non-CodeGen target in public tree was the cpp target which was removed a few years ago so hopefully the API has not regressed without testing. Still I think it would be a good idea to at least evaluate/try this as I've got the feeling lib/CodeGen may get more in the way than being helpful in this case... - Matthias> On May 10, 2017, at 5:26 AM, Neil Henning via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Totally agree Philip! I think the main pending issue is are we allowed to have a target that doesn't go through the normal mechanisms that targets adhere to - and is basically just a ModulePass underneath. > > In light of how thorny this request has been perceived in the past, I'd honestly rather just make external targets work _without_ patching LLVM being a requirement, and then any SPIR-V target (or any other external LLVM targets too!) can live, mature, and prove its usefulness while there is an avenue to use vanilla tip LLVM with the SPIR-V target and go through the normal mechanisms. > > Cheers, > -Codeplay Neil. > > On 2017-05-10 03:52, Philip Reames via llvm-dev wrote: >> On 05/08/2017 10:31 AM, Friedman, Eli via llvm-dev wrote: >>> On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: >>>> On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>>>>> 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. >>>> 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. >>>> 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. >>>> 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. >>>> 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. >>> This is completely skipping over one very important step which is currently part of ISel: legalization. The LLVM optimizers expect backends to support arbitrary-width integers, arbitrary-width vectors, and target-independent intrinsics which are lowered by legalization. SPIR-V does not have native support for these, therefore you need the legalization framework. And the legalization framework in LLVM is fundamentally tied to ISel. >> I'll just add a non-technical point here. Beyond the technical merits >> of "being a target" vs "not being a target" (which I will admit I've >> mostly skipped in this thread because it appears to be repeating >> previously discussed material), there is a *much* lower barrier to >> entry for "being a target". We have standards in place for new >> targets; we're use to thinking about new targets. If you want to add >> something fundamentally new, that will require a lot more design buy >> in and will have to clear a higher bar (in practice.) Given I see >> little evidence of such buy-in to date, pursuing a "not a target >> strategy" will be substantially more risky. >> Philip >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
On 06/21/2017 01:06 PM, Matthias Braun via llvm-dev wrote:> At least in principle LLVM is designed to have Targets that are not based on lib/CodeGen. > > Looking at the APIs it should be possible to just implement TargetMachine (but not LLVMTargetMachine which is only meant for lib/CodeGen targets) and register that with the target registry.Yep, as I recall, the C backend works this way too. The C backend is also not in-tree any more, but there are some fairly-recent forward-ports on github (e.g. https://github.com/JuliaComputing/llvm-cbe/tree/master/lib/Target/CBackend).> > Note that I have never actually done so, so I may be missing some things. It also seems the last non-CodeGen target in public tree was the cpp target which was removed a few years ago so hopefully the API has not regressed without testing. > > Still I think it would be a good idea to at least evaluate/try this as I've got the feeling lib/CodeGen may get more in the way than being helpful in this case...I agree. If there's some capability from CodeGen that you specifically wanted to take advantage of, please elaborate. -Hal> > - Matthias > >> On May 10, 2017, at 5:26 AM, Neil Henning via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Totally agree Philip! I think the main pending issue is are we allowed to have a target that doesn't go through the normal mechanisms that targets adhere to - and is basically just a ModulePass underneath. >> >> In light of how thorny this request has been perceived in the past, I'd honestly rather just make external targets work _without_ patching LLVM being a requirement, and then any SPIR-V target (or any other external LLVM targets too!) can live, mature, and prove its usefulness while there is an avenue to use vanilla tip LLVM with the SPIR-V target and go through the normal mechanisms. >> >> Cheers, >> -Codeplay Neil. >> >> On 2017-05-10 03:52, Philip Reames via llvm-dev wrote: >>> On 05/08/2017 10:31 AM, Friedman, Eli via llvm-dev wrote: >>>> On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: >>>>> On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>>>>>> 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. >>>>> 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. >>>>> 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. >>>>> 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. >>>>> 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. >>>> This is completely skipping over one very important step which is currently part of ISel: legalization. The LLVM optimizers expect backends to support arbitrary-width integers, arbitrary-width vectors, and target-independent intrinsics which are lowered by legalization. SPIR-V does not have native support for these, therefore you need the legalization framework. And the legalization framework in LLVM is fundamentally tied to ISel. >>> I'll just add a non-technical point here. Beyond the technical merits >>> of "being a target" vs "not being a target" (which I will admit I've >>> mostly skipped in this thread because it appears to be repeating >>> previously discussed material), there is a *much* lower barrier to >>> entry for "being a target". We have standards in place for new >>> targets; we're use to thinking about new targets. If you want to add >>> something fundamentally new, that will require a lot more design buy >>> in and will have to clear a higher bar (in practice.) Given I see >>> little evidence of such buy-in to date, pursuing a "not a target >>> strategy" will be substantially more risky. >>> Philip >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory
Yup - entirely possible to have targets that are basically just one or more ModulePass's. I also agree that lib/CodeGen would hinder rather than help us (which is why I stuck with using a few ModulePass's instead!) - Codeplay Neil. On 2017-06-21 19:06, Matthias Braun wrote:> At least in principle LLVM is designed to have Targets that are not > based on lib/CodeGen. > > Looking at the APIs it should be possible to just implement > TargetMachine (but not LLVMTargetMachine which is only meant for > lib/CodeGen targets) and register that with the target registry. > > Note that I have never actually done so, so I may be missing some > things. It also seems the last non-CodeGen target in public tree was > the cpp target which was removed a few years ago so hopefully the API > has not regressed without testing. > > Still I think it would be a good idea to at least evaluate/try this as > I've got the feeling lib/CodeGen may get more in the way than being > helpful in this case... > > - Matthias > >> On May 10, 2017, at 5:26 AM, Neil Henning via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> Totally agree Philip! I think the main pending issue is are we allowed >> to have a target that doesn't go through the normal mechanisms that >> targets adhere to - and is basically just a ModulePass underneath. >> >> In light of how thorny this request has been perceived in the past, >> I'd honestly rather just make external targets work _without_ patching >> LLVM being a requirement, and then any SPIR-V target (or any other >> external LLVM targets too!) can live, mature, and prove its usefulness >> while there is an avenue to use vanilla tip LLVM with the SPIR-V >> target and go through the normal mechanisms. >> >> Cheers, >> -Codeplay Neil. >> >> On 2017-05-10 03:52, Philip Reames via llvm-dev wrote: >>> On 05/08/2017 10:31 AM, Friedman, Eli via llvm-dev wrote: >>>> On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: >>>>> On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>>>>>> 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. >>>>> 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. >>>>> 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. >>>>> 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. >>>>> 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. >>>> This is completely skipping over one very important step which is >>>> currently part of ISel: legalization. The LLVM optimizers expect >>>> backends to support arbitrary-width integers, arbitrary-width >>>> vectors, and target-independent intrinsics which are lowered by >>>> legalization. SPIR-V does not have native support for these, >>>> therefore you need the legalization framework. And the legalization >>>> framework in LLVM is fundamentally tied to ISel. >>> I'll just add a non-technical point here. Beyond the technical >>> merits >>> of "being a target" vs "not being a target" (which I will admit I've >>> mostly skipped in this thread because it appears to be repeating >>> previously discussed material), there is a *much* lower barrier to >>> entry for "being a target". We have standards in place for new >>> targets; we're use to thinking about new targets. If you want to add >>> something fundamentally new, that will require a lot more design buy >>> in and will have to clear a higher bar (in practice.) Given I see >>> little evidence of such buy-in to date, pursuing a "not a target >>> strategy" will be substantially more risky. >>> Philip >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
It's certainly possible to write backends not based on lib/CodeGen, by subclassing TargetMachine instead of LLVMTargetMachine. I've been using this for over a year without problems. On 2017-06-21 20:06, Matthias Braun via llvm-dev wrote:> At least in principle LLVM is designed to have Targets that are not > based on lib/CodeGen. > > Looking at the APIs it should be possible to just implement > TargetMachine (but not LLVMTargetMachine which is only meant for > lib/CodeGen targets) and register that with the target registry. > > Note that I have never actually done so, so I may be missing some > things. It also seems the last non-CodeGen target in public tree was > the cpp target which was removed a few years ago so hopefully the API > has not regressed without testing. > > Still I think it would be a good idea to at least evaluate/try this as > I've got the feeling lib/CodeGen may get more in the way than being > helpful in this case... > > - Matthias > >> On May 10, 2017, at 5:26 AM, Neil Henning via llvm-dev >> <llvm-dev at lists.llvm.org> wrote: >> >> Totally agree Philip! I think the main pending issue is are we allowed >> to have a target that doesn't go through the normal mechanisms that >> targets adhere to - and is basically just a ModulePass underneath. >> >> In light of how thorny this request has been perceived in the past, >> I'd honestly rather just make external targets work _without_ patching >> LLVM being a requirement, and then any SPIR-V target (or any other >> external LLVM targets too!) can live, mature, and prove its usefulness >> while there is an avenue to use vanilla tip LLVM with the SPIR-V >> target and go through the normal mechanisms. >> >> Cheers, >> -Codeplay Neil. >> >> On 2017-05-10 03:52, Philip Reames via llvm-dev wrote: >>> On 05/08/2017 10:31 AM, Friedman, Eli via llvm-dev wrote: >>>> On 5/3/2017 12:04 PM, Tom Stellard via llvm-dev wrote: >>>>> On 05/03/2017 11:19 AM, Nicholas Wilson wrote: >>>>>>> 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. >>>>> 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. >>>>> 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. >>>>> 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. >>>>> 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. >>>> This is completely skipping over one very important step which is >>>> currently part of ISel: legalization. The LLVM optimizers expect >>>> backends to support arbitrary-width integers, arbitrary-width >>>> vectors, and target-independent intrinsics which are lowered by >>>> legalization. SPIR-V does not have native support for these, >>>> therefore you need the legalization framework. And the legalization >>>> framework in LLVM is fundamentally tied to ISel. >>> I'll just add a non-technical point here. Beyond the technical >>> merits >>> of "being a target" vs "not being a target" (which I will admit I've >>> mostly skipped in this thread because it appears to be repeating >>> previously discussed material), there is a *much* lower barrier to >>> entry for "being a target". We have standards in place for new >>> targets; we're use to thinking about new targets. If you want to add >>> something fundamentally new, that will require a lot more design buy >>> in and will have to clear a higher bar (in practice.) Given I see >>> little evidence of such buy-in to date, pursuing a "not a target >>> strategy" will be substantially more risky. >>> Philip >>> _______________________________________________ >>> LLVM Developers mailing list >>> llvm-dev at lists.llvm.org >>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> _______________________________________________ >> LLVM Developers mailing list >> llvm-dev at lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev