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

[Min-Yih Hsu via llvm-dev]

Hi All,

I managed to fix all the patches and make each of them be able to build.
More specifically, patch 3 ~ 6.
Here is the full list of the patches:
1. https://reviews.llvm.org/D88385
2. https://reviews.llvm.org/D88386
3. https://reviews.llvm.org/D88389
4. https://reviews.llvm.org/D88390
5. https://reviews.llvm.org/D88391
6. https://reviews.llvm.org/D88392
7. https://reviews.llvm.org/D88393
8. https://reviews.llvm.org/D88394

Now while I'm addressing the issues from the mailing list and the
Phabricator, I'm wondering if there is any good suggestion on the reviewers?

Thank you

On Mon, Sep 28, 2020 at 2:39 AM Renato Golin <rengolin at gmail.com> wrote:

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


-- 
Min-Yih Hsu
Ph.D Student in ICS Department, University of California, Irvine (UCI).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200930/f88cdcf7/attachment.html>