[llvm-dev] Bountysource campaign for the M68000 backend

[John Paul Adrian Glaubitz via llvm-dev]

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