Upstreaming an new LLVM backend for Renesas RL78

LLVM Project
1

Hello all,

I’m looking to upstream my RL78 port to LLVM.
Initially I though it would be best to upstream as many changes as possible to existing files and in some cases where the reason behind the changes was a bug related to RL78 being 16 bit architecture in which case I was thinking of using msp430 as an example, I have posted 2 of them:
https://reviews.llvm.org/D129689
https://reviews.llvm.org/D127363
However, I was quite slow in responding and I sincerely apologise for this, but this should change as I can focus on this 100% from now on.
I could continue with such changes however they are few in comparison with all the changes I needed to make for RL78 in particular (and are irrelevant to other to other 16 bit targets like msp430) so it will probably be quite dificult to make arguments for those changes without an actual RL78 port present upstream.

The port itself is quite stable I made several releases to customers although there are still many things which I can re-implement in better ways.
So I think it might be easier to upstream the backend first (lib\target<new RL78 folder>) plus minimum changes in cmake files so I don’t break the build for the rest of targets.
If I do this it’s clear it won’t work properly which I think it should be OK since it will in experimental at first or am I wrong and I should continue with small patches to exiting files?
And If I should continue with upstreaming the backend any points I should be aware of or should I just try and push the whole port in phabricator and wait for the comments?

Thank you very much!

2

Beginners isn’t really the right forum to propose a new target. You can start by posting introducing the backend piece by piece. See for example XTensa was split into a 10 part patch series.

3

I moved this to the “LLVM Project” category.

4

Thank you. I will check Xtensa.

Thank you also for moving the post to the right category.

5

You could also take a look at AVR, which is a mixed 8/16-bit architecture. It did encounter similar issues as MSP430, especially in compiler-rt (which needed many small changes to support 16 bit ints).