llvm dev - Aug 2016 - Target Acceptance Policy

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)
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.
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>

On 8/4/2016 12:44 PM, Renato Golin via llvm-dev wrote:
> I still think that's something for the code review.
Would the answer ever change?  Would the reviewers ever say "you should 
implement MC" for one target, and "not doing MC is fine" for
another?

-Krzysztof

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

On Thu, Aug 04, 2016 at 01:12:40PM -0500, Krzysztof Parzyszek via llvm-dev
wrote:
> On 8/4/2016 12:44 PM, Renato Golin via llvm-dev wrote:
> > I still think that's something for the code review.
> 
> Would the answer ever change?  Would the reviewers ever say "you
should
> implement MC" for one target, and "not doing MC is fine" for
another?
It can be formulated in a neutral way as "A new target should use all
applicatable LLVM infrastructure" or so. Not using MC makes sense for a
target that is by nature textual. Not using any of the ISel variants but
rolling custom code on the other hand would be considered a big question
mark.

Joerg