<p dir="ltr"></p>
<p dir="ltr">On 4 Aug 2016 6:26 p.m., "Joerg Sonnenberger via llvm-dev" <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
><br>
> On Thu, Aug 04, 2016 at 06:05:19PM +0100, Renato Golin wrote:<br>
> > On 4 August 2016 at 17:31, Joerg Sonnenberger via llvm-dev<br>
> > <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br>
> > > (1) The list says nothing about using (appropiate) LLVM infrastructure<br>
> > > like the MC subsystem. Should it be a requirements for (new) targets to<br>
> > > support the full source-to-object chain?<br>
> ><br>
> > This is a clear task for code review, not target inclusion policy.<br>
> ><br>
> > This list is supposed to be timeless, and adding any kind of specific<br>
> > technology would need updating all the time, and can even have<br>
> > conflicting views (like MCJIT vs ORCJIT vs the new cool toy), or the<br>
> > old pass manager, vs. the new one, or FastISel vs SelectionDAG vs.<br>
> > GlobalISel, etc.<br>
><br>
> The choice of ISel is ephemeral and not relevant outside the specific<br>
> target. MCJIT vs ORCJIT has very limited impact on both the target and<br>
> target neutral code. Using/supporting MC on the other hand is a decision<br>
> quite on the architectural level as it is a prerequirement for things<br>
> like MCJIT/ORCJIT. Note that I didn't say anything about requiring<br>
> AsmParser support, just MC.<br></p>
<p dir="ltr">I still think that's something for the code review.</p>
<p dir="ltr">Cheers, <br>
Renato <br>
</p>