[llvm-dev] [RFC] Backend for Motorola 6800 series CPU (M68k)

[Min-Yih Hsu via llvm-dev]

Hi All,

Thank you for all the feedbacks!

@Adrian, thank you again for setting up the build bot

@MaskRay @Renato @David, thanks for clarifying the processing. I’m also glad that no one  is standing against M68k. However I’m also aware that there are only few reviewers on the list. And that’s probably the main reason why those patches were stalling in the past few months. Therefore I think it’s a good idea to put everyone in this thread as reviewers for now. If you’re not confident on reviewing some of the patches, please feel free to ping others that might be interested in reviewing it.
And @David, thanks for letting us know the situation on the CSKY backend, I’ll take a look.

Best,
- Min


> On Nov 16, 2020, at 2:40 AM, John Paul Adrian Glaubitz via llvm-dev <llvm-dev at lists.llvm.org> wrote:
> 
> Hello David!
> 
> On 11/16/20 11:30 AM, David Chisnall via llvm-dev wrote:
>> Generally, the bar for being in-tree is fairly low, the bar to being removed
>> from the experimental-back-ends list is much higher.  An experimental back end
>> is not built by default and is not in any of the binary releases.
>> 
>> Experimental back ends provide a probation period for the maintainer community.
>> If bugs are fixed regularly, the back end makes good progress, the required
>> infrastructure is maintained, there's engagement from the maintainers in reviewing
>> other patches then it's easy to get the back end promoted to non-experimental.
>> If not, then it will languish in the experimental state for a while and then
>> eventually be removed (this will typically happen much faster if it requires
>> any infrastructure in the generic CodeGen logic to support it and is imposing
>> a maintenance cost on the rest of the compiler).
> 
> Thanks for elaborating this and I think this is actually the way to go, for any
> such project. It's a fair deal between both the upstream project and the new
> maintainers.
> 
> It allows us to get a fair chance, on the other hand, it still gives LLVM upstream
> the possibility to decide about the production readyness of the backend and consequently
> whether it's worth to keep or not.
> 
>> It sounds as if there's a fairly active community of m68k enthusiasts (I'm assuming
>> that, in spite of the title of this thread, we are talking about the 68000, not the 6800),
>> so I expect that the promotion to supported back end should go fairly smoothly.
> 
> Yes, despite its age, the architecture is still very popular. It has only little commercial
> relevance, unsurprisingly, but there is still new hardware being made and there are
> even new variants of the CPU being developed by the community, notably the 68080.
> 
> For me personally, LLVM is an incredibly interesting and important project and I'm more
> than thrilled that we are getting a chance to upstream our backend into LLVM's
> repository.
> 
> I'm currently trying to ramp up my personal effort to contribute to LLVM and make sure
> we're getting the backend supported on the targets we have in Debian.
> 
> I have already set up a buildbot worker for linux-sparc64 that is being used and another one
> for linux-m68k is ready and waiting. I will later add one for MIPS (I've got a fairly
> fast Loongson board) and one for 32-bit PowerPC.
> 
>> Note that, so far, I've been about the only person reviewing the CSKY patches and have
>> very little spare bandwidth to do it at the moment. I'd encourage the m68k maintainers
>> to take a look at it and help out as good community members.  All of the back ends in LLVM
>> would be better if more people reviewed code for back ends other than the one or two that
>> they work on.
> 
> I currently don't have the expertise to do so. But as I previously stated, I'm very interested
> to help keep LLVM in shape on the backends that are being used in Debian, especially the
> less popular ones as I know that ARM, PPC and X86 are very well maintained.
> 
> Thanks,
> 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
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev