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

On Mon, 28 Sep 2020 at 10:37, John Paul Adrian Glaubitz <
glaubitz at physik.fu-berlin.de> wrote:
> So, I think in case there was a problem with the backend in LLVM, the
> community
> would have enough momentum to work towards solving this issue.
>
Great!

I agree. But we will enable the target in Debian the moment it
becomes
> usable
> and we will expose it to as much testing as possible to unconver bugs or
> remaining
> features and report them upstream.
>
That's good to hear. The Debian project has helped us do extensive tests in
other hardware and it provided us with confidence that what we build
actually works in some real world context.


We have a rough list of remaining issues in [1] and [2]. Min also gave
a
> talk
> in [3] where he drafted out the TODO and plans for the backend [3]. The
> talk
> is also available on Youtube [4].
>
So, IIUC, the current implementation is reasonably complete. You're able to
compile C programs and run them on real hardware. The main effort now is to
upstream what you have, and continue the development.

This would make the "plan" easier. Getting the current state upstream
would
make for a nice experimental target. Getting Debian packages compiled and
tested with QEMU would demonstrate production quality.

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

Hi Renato,

Thanks for all your feedback, those were extremely helpful, especially the
guidelines to split the patches. I think in my case, patch 3 ~ 6 are the
most problematic, I will rework them shortly.

And most importantly, I'll present a roadmap regarding blockers we need to
clear and milestones to reach before graduating from experimental targets.
We'll also try to prepare the buildbot, as well as testing bots running
m68k QEMU (IIUC, we need to prepare our own server...right?)

Best,
Min

On Mon, Sep 28, 2020 at 2:57 AM Renato Golin <rengolin at gmail.com>
wrote:
> On Mon, 28 Sep 2020 at 10:37, John Paul Adrian Glaubitz <
> glaubitz at physik.fu-berlin.de> wrote:
>
>> So, I think in case there was a problem with the backend in LLVM, the
>> community
>> would have enough momentum to work towards solving this issue.
>>
>
> Great!
>
> I agree. But we will enable the target in Debian the moment it becomes
>> usable
>> and we will expose it to as much testing as possible to unconver bugs
or
>> remaining
>> features and report them upstream.
>>
>
> That's good to hear. The Debian project has helped us do extensive
tests
> in other hardware and it provided us with confidence that what we build
> actually works in some real world context.
>
>
> We have a rough list of remaining issues in [1] and [2]. Min also gave a
>> talk
>> in [3] where he drafted out the TODO and plans for the backend [3]. The
>> talk
>> is also available on Youtube [4].
>>
>
> So, IIUC, the current implementation is reasonably complete. You're
able
> to compile C programs and run them on real hardware. The main effort now is
> to upstream what you have, and continue the development.
>
> This would make the "plan" easier. Getting the current state
upstream
> would make for a nice experimental target. Getting Debian packages compiled
> and tested with QEMU would demonstrate production quality.
>
> 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/20200928/08399497/attachment.html>

On Mon, 28 Sep 2020 at 19:13, Min-Yih Hsu <minyihh at uci.edu> wrote:
> Thanks for all your feedback, those were extremely helpful, especially the
> guidelines to split the patches. I think in my case, patch 3 ~ 6 are the
> most problematic, I will rework them shortly.
>
Perfect, thanks!

And most importantly, I'll present a roadmap regarding blockers we need
to
> clear and milestones to reach before graduating from experimental targets.
>
Great!

This would be slightly different than the Github issues, and should be
focused on the two milestones: adding the backend as experimental (ie, what
you have today) and moving to production. Both should have a list of
features that are expected to exist / be implemented and some rough time
frame to get there.

Given you already have what looks like a working back-end (maybe not
production yet, but), I'm expecting the experimental target to be more in
shape than some others we had recently.

You should, however, expect more reviews on policy (style, patterns,
containers), due to the previous separate nature of the development. This
is to make sure the code goes in in a way that everybody else understands
and can change. Don't take this as a measure of code quality, only style
adjustment to the new community.

We'll also try to prepare the buildbot, as well as testing bots
running
> m68k QEMU (IIUC, we need to prepare our own server...right?)
>
Right.

During the experimental phase, none of the other buildbots will be building
your target, so you must make sure at least one is. This can be running on
any hardware (x86, arm, etc) but needs to be building the experimental
back-end and running all its tests (check-all).

Once the target moves on to production, most other bots will be building it
and testing, so you don't need that simple builder any more. But you can
have builders with different configurations that aren't built by any other
builder out there, to increase coverage and trust in your back-end.

You should also eventually try to run the LLVM test-suite on the target.
I'm not sure it's possible to run all, due to the aged nature of the
68k,
or if the tests will produce the same results (we had some trouble on Arm
vs x86, for example). But trying to run them and understanding the issues
gives you a lot of good information about your back-end.

The Debian tests are similar to the test-suite. Their builds will be slower
than a standard bot cycle and so will end up queueing a lot of commits. It
will be harder to investigate the issues, you'll need longer bisects,
codegen tests, etc.

All buildbots should initially be in the "silent master" (ie no email
warnings when they break), and your community should monitor them closely.

Once the target leaves experimental, and we expect all bots to be mostly
green by then, you can move the builders to the "loud master", which
will
start nagging people when they break the build.

The expectation is that, by then, things will be stable enough (one of the
criteria to move to production) that the noise will be no more annoying
than any other buildbot, and consisting mostly of true positives.

cheers,
--renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20200929/1b00f53a/attachment.html>

On 9/28/20 11:56 AM, Renato Golin wrote:
> That's good to hear. The Debian project has helped us do extensive
tests in
> other hardware and it provided us with confidence that what we build
> actually works in some real world context.
And, FWIW, please let us know whenever you need help with testing LLVM on
less common targets. I have access to every architecture supported by
Debian and own machines with most of these targets.

We also try to provide as many different architectures through the GCC compile
farm that anyone can use who is developing open source software:
> https://gcc.gnu.org/wiki/CompileFarm
So, whenever you need assistance with architectures like SPARC, please let
us know :).
> We have a rough list of remaining issues in [1] and [2]. Min also gave a
>> talk
>> in [3] where he drafted out the TODO and plans for the backend [3]. The
>> talk
>> is also available on Youtube [4].
>>
> 
> So, IIUC, the current implementation is reasonably complete. You're
able to
> compile C programs and run them on real hardware. The main effort now is to
> upstream what you have, and continue the development.
Yes, that would be awesome.
> This would make the "plan" easier. Getting the current state
upstream would
> make for a nice experimental target. Getting Debian packages compiled and
> tested with QEMU would demonstrate production quality.
Sounds good.

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