llvm dev - Mar 2020 - Bountysource campaign for the M68000 backend

Hello!

Almost two years ago, Artyom Goncharov submitted an initial effort for a
backend for the Motorola 68000 architecture [1] which was eventually
not merged, unfortunately. I elaborated why I supported the idea of
such a backend [2].

Recently, we started a fundraising campaign on the platform Bountysource.com
to port the M68K backend in GCC to the new MODE_CC register representation
which was very successful collecting over $6000 in donations financing an
experienced GCC developer to complete the task in a short period [3].

Due to the success of the GCC campaign, people in the Amiga community are
wondering whether such a campaign would work for LLVM as well to complete
the M68000 backend started by Artyom [4] and maybe also get it merged
into LLVM upstream. The list of remaining tasks on the backend are tracked
in the issue tracker for the M68000 backend on Github.

I think such a backend has good chances of attracting maintainers and
developers as there is still a considerably large community around the
M68000 architecture. I recently learned that there are even people at
Google working on Amiga code in their free time.

What does the LLVM community think? Would it be okay in principle to start
such a fundraising campaign and would there be someone on the list interesting
on working on this project provided that we are able to collect enough
funds?

Thanks,
Adrian
> [1] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html
> [2] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125325.html
> [3]
https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> [4] https://github.com/M680x0/M680x0-llvm
-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Hi John,

I don't speak for the entire community, but I believe that there are 
likely to be two potential issues:

1. How different is M68K to modern architectures (reluctantly including 
x86)?  Will this add any maintenance burden to the target-agnostic code 
generator?  If so, how much and will there be contributors willing to 
help carry that to retain M68K support?
2. Who is going to commit to maintaining the port?  For example, the 
original version used SelectionDAG, which will eventually be phased out 
in favour of GlobalISel.  This involves some quite major changes to back 
ends, which is why back ends are only committed if they have a code 
owner who is willing to provide long-term maintenance.

I don't think that a one-off donation mechanism is a great way of 
getting someone to do this long-term, but if you have someone in mind 
who is willing to do it but needs some seed capital to get it into a 
good state initially, that may work.

LLVM, in general, is pretty happy to remove things that are slowing down 
development and have no active maintainers, so if the M68K maintainer 
went away there is a danger that the back end would be dropped.  How 
would backers of the bounty program react if the code were added, the 
bounty paid, and then the code removed a year later?  I think I'd be 
pretty annoyed if I'd paid into something like that on the assumption 
that I'd have an LLVM back end, but end up with an LLVM 11 and LLVM 12 
back end that is then not in LLVM 13.

If you can come up with a plan for long-term maintenance (ideally a 
small group of people willing to say 'we will do code review of the 
initial implementation and then maintain it'), then I think this would 
be a great contribution.

David

On 24/03/2020 22:36, John Paul Adrian Glaubitz via llvm-dev
wrote:
> Hello!
> 
> Almost two years ago, Artyom Goncharov submitted an initial effort for a
> backend for the Motorola 68000 architecture [1] which was eventually
> not merged, unfortunately. I elaborated why I supported the idea of
> such a backend [2].
> 
> Recently, we started a fundraising campaign on the platform
Bountysource.com
> to port the M68K backend in GCC to the new MODE_CC register representation
> which was very successful collecting over $6000 in donations financing an
> experienced GCC developer to complete the task in a short period [3].
> 
> Due to the success of the GCC campaign, people in the Amiga community are
> wondering whether such a campaign would work for LLVM as well to complete
> the M68000 backend started by Artyom [4] and maybe also get it merged
> into LLVM upstream. The list of remaining tasks on the backend are tracked
> in the issue tracker for the M68000 backend on Github.
> 
> I think such a backend has good chances of attracting maintainers and
> developers as there is still a considerably large community around the
> M68000 architecture. I recently learned that there are even people at
> Google working on Amiga code in their free time.
> 
> What does the LLVM community think? Would it be okay in principle to start
> such a fundraising campaign and would there be someone on the list
interesting
> on working on this project provided that we are able to collect enough
> funds?
> 
> Thanks,
> Adrian
> 
>> [1] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html
>> [2] https://lists.llvm.org/pipermail/llvm-dev/2018-August/125325.html
>> [3]
https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
>> [4] https://github.com/M680x0/M680x0-llvm
>

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

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.

- Dave

On Wed, Mar 25, 2020 at 4:32 AM David Chisnall via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> Hi John,
>
> I don't speak for the entire community, but I believe that there are
> likely to be two potential issues:
>
> 1. How different is M68K to modern architectures (reluctantly including
> x86)?  Will this add any maintenance burden to the target-agnostic code
> generator?  If so, how much and will there be contributors willing to
> help carry that to retain M68K support?
> 2. Who is going to commit to maintaining the port?  For example, the
> original version used SelectionDAG, which will eventually be phased out
> in favour of GlobalISel.  This involves some quite major changes to back
> ends, which is why back ends are only committed if they have a code
> owner who is willing to provide long-term maintenance.
>
> I don't think that a one-off donation mechanism is a great way of
> getting someone to do this long-term, but if you have someone in mind
> who is willing to do it but needs some seed capital to get it into a
> good state initially, that may work.
>
> LLVM, in general, is pretty happy to remove things that are slowing down
> development and have no active maintainers, so if the M68K maintainer
> went away there is a danger that the back end would be dropped.  How
> would backers of the bounty program react if the code were added, the
> bounty paid, and then the code removed a year later?  I think I'd be
> pretty annoyed if I'd paid into something like that on the assumption
> that I'd have an LLVM back end, but end up with an LLVM 11 and LLVM 12
> back end that is then not in LLVM 13.
>
> If you can come up with a plan for long-term maintenance (ideally a
> small group of people willing to say 'we will do code review of the
> initial implementation and then maintain it'), then I think this would
> be a great contribution.
>
> David
>
> On 24/03/2020 22:36, John Paul Adrian Glaubitz via llvm-dev wrote:
> > Hello!
> >
> > Almost two years ago, Artyom Goncharov submitted an initial effort for
a
> > backend for the Motorola 68000 architecture [1] which was eventually
> > not merged, unfortunately. I elaborated why I supported the idea of
> > such a backend [2].
> >
> > Recently, we started a fundraising campaign on the platform
> Bountysource.com
> > to port the M68K backend in GCC to the new MODE_CC register
> representation
> > which was very successful collecting over $6000 in donations financing
an
> > experienced GCC developer to complete the task in a short period [3].
> >
> > Due to the success of the GCC campaign, people in the Amiga community
are
> > wondering whether such a campaign would work for LLVM as well to
complete
> > the M68000 backend started by Artyom [4] and maybe also get it merged
> > into LLVM upstream. The list of remaining tasks on the backend are
> tracked
> > in the issue tracker for the M68000 backend on Github.
> >
> > I think such a backend has good chances of attracting maintainers and
> > developers as there is still a considerably large community around the
> > M68000 architecture. I recently learned that there are even people at
> > Google working on Amiga code in their free time.
> >
> > What does the LLVM community think? Would it be okay in principle to
> start
> > such a fundraising campaign and would there be someone on the list
> interesting
> > on working on this project provided that we are able to collect enough
> > funds?
> >
> > Thanks,
> > Adrian
> >
> >> [1]
https://lists.llvm.org/pipermail/llvm-dev/2018-August/125317.html
> >> [2]
https://lists.llvm.org/pipermail/llvm-dev/2018-August/125325.html
> >> [3]
>
https://www.bountysource.com/issues/80706251-m68k-convert-the-backend-to-mode_cc-so-it-can-be-kept-in-future-releases
> >> [4] https://github.com/M680x0/M680x0-llvm
> >
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200325/a06a3b40/attachment.html>

Hi David!

Thanks a lot for your feedback!

On 3/25/20 12:31 PM, David Chisnall via llvm-dev wrote:
> I don't speak for the entire community, but I believe that there are
likely to be two potential issues:
> 
> 1. How different is M68K to modern architectures (reluctantly including
x86)?  Will this add any
>    maintenance burden to the target-agnostic code generator?
I don't think m68k is particularly odd. It does not have a stack growing
into the opposite
direction or even two stacks like ia64 and has equivalent instructions for most
instructions
that x86 has. There is even full support for compare-and-swap despite the
architecture
being so old unlike older SPARC or older ARM.

The only oddity of m68k on Linux is that the default alignment is 2 bytes
instead of 4 bytes,
despite the architecture being 32 bits.
> If so, how much and will there be  contributors willing to help carry that
to retain M68K support?
We don't have any dedicated maintainer for the LLVM m68k backend yet, but my
hope is to find
one through this mailing list or another community. As I have mentioned in my
first mail,
there are a lot of developers in the community and at companies due to the
popularity of
the Amiga.
> 2. Who is going to commit to maintaining the port?  For example, the
original version used
>    SelectionDAG, which will eventually be phased out in favour of
GlobalISel.  This involves
>    some quite major changes to back ends, which is why back ends are only
committed if they
>    have a code owner who is willing to provide long-term maintenance.
Since we're still looking for a dedicated maintainer, I cannot answer this
question yet,
unfortunately.
> I don't think that a one-off donation mechanism is a great way of
getting someone to do this
> long-term, but if you have someone in mind who is willing to do it but
needs some seed capital
> to get it into a good state initially, that may work.
I fully agree and I understand that LLVM is a very volatile project.
> LLVM, in general, is pretty happy to remove things that are slowing down
development and
> have no active maintainers, so if the M68K maintainer went away there is a
danger that
> the back end would be dropped.
Yes, I know this and I think in one sense this is very unfortunate. LLVM is
really a key
project these days and having backend support for a particular architecture in
LLVM
means that one gets support for a variety of new languages and technologies with
very
little effort since LLVM is so incredibly versatile.

For example, adding support for a new architecture in Rust requires probably
less than
500 lines of code once LLVM has support for this architecture. And with more and
more
projects including Rust in their code bases, being a supported backend
architecture
in LLVM becomes more and more attractive.
> How would backers of the bounty program react if the code were added, the
bounty paid,
> and then the code removed a year later?  I think I'd be pretty annoyed
if I'd paid into
> something like that on the assumption that I'd have an LLVM back end,
but end up with
> an LLVM 11 and LLVM 12 back end that is then not in LLVM 13.
Yes, I absolutely agree that this is a problem and I don't know a particular
solution
to this yet. I think it's really a pity that the barrier for getting into
LLVM is so
high.
> If you can come up with a plan for long-term maintenance (ideally a small
group of people
> willing to say 'we will do code review of the initial implementation
and then maintain it'),
> then I think this would be a great contribution.
That might be a good idea. FWIW, QEMU has pretty good emulation support for m68k
these
days. In fact, the GCC developer who recently converted the m68k backend in GCC
to
MODE_CC used QEMU as well running a current version of Debian unstable.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaubitz at debian.org
`. `'   Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913