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

[Renato Golin via cfe-dev]

On Mon, 28 Sep 2020 at 06:44, Min-Yih Hsu via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> As Nicloas mentioned, you need to compile all 8 patches as a whole. Which
> I think is not ideal from the point of reviewers. So I'm wondering what is
> the suggestion on splitting a new target backend?
>

This is problematic for regression testing and bisecting to find a broken
commit. The guideline is to split the patch into multiple commits, but that
each commit builds on their own.

They don't need to have tests in between and be fully functional, but they
need to compile and not to break anything.

Usually (and very generally) people break new targets into a few steps:
 1. Adds the new directory, base table-gen files, hooks on CMake, etc.
 2. Adds target description in table-gen (registers, etc) and operations.
[this could be split in two if large]
 3. Adds codegen hooks from MIR and gets some initial "hello world"
compiled, add tests for the features added

Steps 1 and 2 should not break anything else. Step 3's tests should all
pass and not break other tests. There could be more commits than 1 per
step, but not breaking build/tests nor depending on future patches.

You should also have a buildbot with the target enabled (there's a CMake
flag for that) to show that it's green most of the time.

Optional but nice, you could have some kind of testing on "hardware" (which
could be an emulator). Does QEMU have user emulation for 68k?

You don't need to add all hardware features nor all operations in the first
patch-set, but it's nice if the first wave can compile a hello world
program.

That's where the plan comes in. We usually ask the new community to provide
a roadmap of what features will come in which order, so that we can help
with the plan and be prepared to review the code. It also gives us more
confidence that the community is serious about adding a production target,
not just a toy target.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200928/b4f48154/attachment-0001.html>