On 4 August 2016 at 17:31, Joerg Sonnenberger via llvm-dev <llvm-dev at lists.llvm.org> wrote:> (1) The list says nothing about using (appropiate) LLVM infrastructure > like the MC subsystem. Should it be a requirements for (new) targets to > support the full source-to-object chain?Hi Joerg, This is a clear task for code review, not target inclusion policy. This list is supposed to be timeless, and adding any kind of specific technology would need updating all the time, and can even have conflicting views (like MCJIT vs ORCJIT vs the new cool toy), or the old pass manager, vs. the new one, or FastISel vs SelectionDAG vs. GlobalISel, etc.> (2) What are the criterions for reviving targets? Consider the Alpha or > Itanium target.When a target is deprecated, it probably means its code is so old and rotten that it doesn't work any more, or that whatever it was meant to be doing, it's not doing any more. With that in mind, if anyone wants to modernise the code, they'll probably have to re-write most of it, and then it becomes a new back-end. Also, the community of deprecated targets has clearly failed some of the pre-requisites, so asking them to prove again would only be fair. cheers, --renato
On Thu, Aug 04, 2016 at 06:05:19PM +0100, Renato Golin wrote:> On 4 August 2016 at 17:31, Joerg Sonnenberger via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > (1) The list says nothing about using (appropiate) LLVM infrastructure > > like the MC subsystem. Should it be a requirements for (new) targets to > > support the full source-to-object chain? > > This is a clear task for code review, not target inclusion policy. > > This list is supposed to be timeless, and adding any kind of specific > technology would need updating all the time, and can even have > conflicting views (like MCJIT vs ORCJIT vs the new cool toy), or the > old pass manager, vs. the new one, or FastISel vs SelectionDAG vs. > GlobalISel, etc.The choice of ISel is ephemeral and not relevant outside the specific target. MCJIT vs ORCJIT has very limited impact on both the target and target neutral code. Using/supporting MC on the other hand is a decision quite on the architectural level as it is a prerequirement for things like MCJIT/ORCJIT. Note that I didn't say anything about requiring AsmParser support, just MC. Joerg
On 4 Aug 2016 6:26 p.m., "Joerg Sonnenberger via llvm-dev" < llvm-dev at lists.llvm.org> wrote:> > On Thu, Aug 04, 2016 at 06:05:19PM +0100, Renato Golin wrote: > > On 4 August 2016 at 17:31, Joerg Sonnenberger via llvm-dev > > <llvm-dev at lists.llvm.org> wrote: > > > (1) The list says nothing about using (appropiate) LLVM infrastructure > > > like the MC subsystem. Should it be a requirements for (new) targetsto> > > support the full source-to-object chain? > > > > This is a clear task for code review, not target inclusion policy. > > > > This list is supposed to be timeless, and adding any kind of specific > > technology would need updating all the time, and can even have > > conflicting views (like MCJIT vs ORCJIT vs the new cool toy), or the > > old pass manager, vs. the new one, or FastISel vs SelectionDAG vs. > > GlobalISel, etc. > > The choice of ISel is ephemeral and not relevant outside the specific > target. MCJIT vs ORCJIT has very limited impact on both the target and > target neutral code. Using/supporting MC on the other hand is a decision > quite on the architectural level as it is a prerequirement for things > like MCJIT/ORCJIT. Note that I didn't say anything about requiring > AsmParser support, just MC.I still think that's something for the code review. Cheers, Renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160804/d6ce0a88/attachment.html>