Upstreaming an new LLVM backend for Renesas RL78

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!

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.

I moved this to the “LLVM Project” category.

Thank you. I will check Xtensa.

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

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

Sorry I have a few more questions:
I posted the first patch here:
https://reviews.llvm.org/D150693

I had one review comment which I solved and I got accepted by the same reviewer however nothing else happens and I suspect is due to the following message:
Build 359170: pre-merge checks x64 debian FAILED

I suspect this is a formatting issue. Is this correct?
If yes, I tried to use git-clang-format as described here:
https://www.llvm.org/docs/Contributing.html
however it modified all the lines not just the modified ones which is odd since this is what the first line of comment in the script says.
So I tried to format manually.
Any ideas what I might have gone wrong? Thank you!

If you don’t have commit access, you should comment on the patch (with your name and email) and ask someone to commit it for you.

I don’t think we can land ⚙ D150693 [RL78 patch 1] Recognize RL78 in triple parsing code now. M68k is a good precedent to follow. All the needed patches were prepared and each was reviewed. Then the author landed the first patch, then the second, and so on. Xtensa patches were done in a similar manner. We don’t want half-baked things in the tree.

1 Like

I disagree for the triple patch specifically. IMO anything can go into Triple even if no backend were ever to be upstreamed