<div dir="ltr">Yeah, I'd agree pretty much with what David Chisnall said - that this might not be the best way to get something into LLVM. A short term contract without other demonstrated community involvement (even with the position that it'll come after the short term contract) is sort of a clear example of what wouldn't be good to have committed to the LLVM project itself. Though the experimental targets system would at least provide an in-tree way to get the target in and demonstrate continued community involvement (but with the risk, as David pointed out, that if that ongoing involvement doesn't eventuate, the target would be deleted and some people who paid for the target work might be disheartened).<br><br>Maybe a github fork would be a better place to start such work - setting expectations a bit lower, less resentment because it wouldn't be deleted due to lack of maintenance & if it is well maintained, that might help provide the demonstrated ongoing interest that would be useful in adding it as an experimental target and then hopefully non-experimental.<br><br>- Dave</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 25, 2020 at 4:32 AM David Chisnall via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi John,<br>
<br>
I don't speak for the entire community, but I believe that there are <br>
likely to be two potential issues:<br>
<br>
1. How different is M68K to modern architectures (reluctantly including <br>
x86)?  Will this add any maintenance burden to the target-agnostic code <br>
generator?  If so, how much and will there be contributors willing to <br>
help carry that to retain M68K support?<br>
2. Who is going to commit to maintaining the port?  For example, the <br>
original version used SelectionDAG, which will eventually be phased out <br>
in favour of GlobalISel.  This involves some quite major changes to back <br>
ends, which is why back ends are only committed if they have a code <br>
owner who is willing to provide long-term maintenance.<br>
<br>
I don't think that a one-off donation mechanism is a great way of <br>
getting someone to do this long-term, but if you have someone in mind <br>
who is willing to do it but needs some seed capital to get it into a <br>
good state initially, that may work.<br>
<br>
LLVM, in general, is pretty happy to remove things that are slowing down <br>
development and have no active maintainers, so if the M68K maintainer <br>
went away there is a danger that the back end would be dropped.  How <br>
would backers of the bounty program react if the code were added, the <br>
bounty paid, and then the code removed a year later?  I think I'd be <br>
pretty annoyed if I'd paid into something like that on the assumption <br>
that I'd have an LLVM back end, but end up with an LLVM 11 and LLVM 12 <br>
back end that is then not in LLVM 13.<br>
<br>
If you can come up with a plan for long-term maintenance (ideally a <br>
small group of people willing to say 'we will do code review of the <br>
initial implementation and then maintain it'), then I think this would <br>
be a great contribution.<br>
<br>
David<br>
<br>
On 24/03/2020 22:36, John Paul Adrian Glaubitz via llvm-dev wrote:<br>
> Hello!<br>
> <br>
> Almost two years ago, Artyom Goncharov submitted an initial effort for a<br>
> backend for the Motorola 68000 architecture [1] which was eventually<br>
> not merged, unfortunately. I elaborated why I supported the idea of<br>
> such a backend [2].<br>
> <br>
> Recently, we started a fundraising campaign on the platform Bountysource.com<br>
> to port the M68K backend in GCC to the new MODE_CC register representation<br>
> which was very successful collecting over $6000 in donations financing an<br>
> experienced GCC developer to complete the task in a short period [3].<br>
> <br>
> Due to the success of the GCC campaign, people in the Amiga community are<br>
> wondering whether such a campaign would work for LLVM as well to complete<br>
> the M68000 backend started by Artyom [4] and maybe also get it merged<br>
> into LLVM upstream. The list of remaining tasks on the backend are tracked<br>
> in the issue tracker for the M68000 backend on Github.<br>
> <br>
> I think such a backend has good chances of attracting maintainers and<br>
> developers as there is still a considerably large community around the<br>
> M68000 architecture. I recently learned that there are even people at<br>
> Google working on Amiga code in their free time.<br>
> <br>
> What does the LLVM community think? Would it be okay in principle to start<br>
> such a fundraising campaign and would there be someone on the list interesting<br>
> on working on this project provided that we are able to collect enough<br>
> funds?<br>
> <br>
> Thanks,<br>
> Adrian<br>
> <br>
>> [1] <a href="https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html</a><br>
>> [2] <a href="https://lists.llvm.org/pipermail/llvm-dev/2018-August/125325.html" rel="noreferrer" target="_blank">https://lists.llvm.org/pipermail/llvm-dev/2018-August/125325.html</a><br>
>> [3] <a href="https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases" rel="noreferrer" target="_blank">https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases</a><br>
>> [4] <a href="https://github.com/M680x0/M680x0-llvm" rel="noreferrer" target="_blank">https://github.com/M680x0/M680x0-llvm</a><br>
> <br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>