<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 26, 2020 at 10:28 AM Sebastian Perta <<a href="mailto:Sebastian.Perta@renesas.com">Sebastian.Perta@renesas.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div lang="EN-GB">
<div class="gmail-m_4914467080524297474WordSection1">
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Hi David,<u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Thank for very much for your reply!<u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">I got a reply on the clang mailing list in April
from Dmitri:<u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><a href="http://lists.llvm.org/pipermail/cfe-dev/2020-April/065115.html" target="_blank">http://lists.llvm.org/pipermail/cfe-dev/2020-April/065115.html</a><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">and following his advice “attaching pragmas as attributes
to functions” I managed to do it, it was actually quite easy.</span></font></p></div></div></blockquote><div><br></div><div>Oh, great - glad you got some traction! (I was just replying as sort of a last-resort, none of this is really my wheelhouse)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_4914467080524297474WordSection1"><p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> </span></font><span style="font-size:11pt;font-family:Calibri">>>Compatibility with an existing compiler is usually compelling - are the compilers you're trying to be compatible with publicly available/documented?</span></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Yes the compiler can be downloaded from here (is available for free with some restrictions compared to the paid version).
</span></font><span><u></u><u></u></span></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><a href="https://www.renesas.com/in/en/products/software-tools/tools/compiler-assembler/compiler-package-for-rl78-family.html" target="_blank">https://www.renesas.com/in/en/products/software-tools/tools/compiler-assembler/compiler-package-for-rl78-family.html</a><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">The documentation is available as well (in toolchain
installer and website): <u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><a href="https://www.renesas.com/in/en/doc/products/tool/doc/015/r20ut3123ej0109-ccrl.pdf" target="_blank">https://www.renesas.com/in/en/doc/products/tool/doc/015/r20ut3123ej0109-ccrl.pdf</a><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">>>The other aspect to new features, targets, etc, is the ongoing support - might be relevant to know a bit more about you/your users, whether there are other folks who are likely
to maintain this work if you stop being involved at some point, etc.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Sure, no problem!<u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">About me:
<a href="https://ro.linkedin.com/in/sebastian-perta-46a4383b" target="_blank">https://ro.linkedin.com/in/sebastian-perta-46a4383b</a><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Currently I have no intentions of stop being involved in this for a very long time. The only way this can happen is if I decide to leave Renesas in which case I’m sure the company
will be interested to find a replacement.</span></font></p></div></div></blockquote><div><br>Ah, so this is a commercially backed project? But relatively small? (are you the only engineer working on this?)<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_4914467080524297474WordSection1"><p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">About the users: those are embedded engineers in automotive, IOT, domestic appliances, etc.<u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Anything else you would like to know?</span></font></p></div></div></blockquote><div><br>It's never a clear-cut thing and I don't mean to pry (there's a weird balance between having some context for why these things are being worked on, how likely they are to continue to be invested in, etc - versus accepting that companies have their own priorities, some private objectives, etc).<br><br>- Dave<br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-GB"><div class="gmail-m_4914467080524297474WordSection1"><p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u><u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Best Regards,<br>
Sebastian</span></font><span><u></u><u></u></span></p>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0cm 0cm 0cm 4pt">
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0cm 0cm">
<p class="MsoNormal"><b><font size="2" face="Calibri"><span lang="EN-US" style="font-size:11pt;font-weight:bold">From:</span></font></b><span lang="EN-US">
David Blaikie <<a href="mailto:dblaikie@gmail.com" target="_blank">dblaikie@gmail.com</a>> <br>
<b><span style="font-weight:bold">Sent:</span></b> 26 May 2020 17:46<br>
<b><span style="font-weight:bold">To:</span></b> Sebastian Perta <<a href="mailto:Sebastian.Perta@renesas.com" target="_blank">Sebastian.Perta@renesas.com</a>>; Aaron Ballman <<a href="mailto:aaron@aaronballman.com" target="_blank">aaron@aaronballman.com</a>>; Richard Smith <<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>><br>
<b><span style="font-weight:bold">Cc:</span></b> <a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<b><span style="font-weight:bold">Subject:</span></b> Re: [llvm-dev] New LLVM backend for Renesas RL78 MCU<u></u><u></u></span></p>
</div>
</div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">+Aaron as the attribution expert<br>
+Richard for general Clang things<br>
<br>
I imagine there might be some interest in a pragma that applies an attribute to a function - I know Apple folks implemented some attribution framework based on an input file, so attributing-at-a-distance is roughly in the realms of plausible.<br>
Compatibility with an existing compiler is usually compelling - are the compilers you're trying to be compatible with publicly available/documented?<br>
The other aspect to new features, targets, etc, is the ongoing support - might be relevant to know a bit more about you/your users, whether there are other folks who are likely to maintain this work if you stop being involved at some point, etc.<u></u><u></u></span></font></p>
</div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt"><u></u> <u></u></span></font></p>
<div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">On Wed, Apr 1, 2020 at 10:26 AM Sebastian Perta via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>> wrote:<u></u><u></u></span></font></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0cm 0cm 0cm 6pt;margin-left:4.8pt;margin-right:0cm">
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:11pt">Hello all,<br>
<br>
For the past couple of months I've been writing a new llvm backend for Renesas RL78 MCU:<br>
<a href="https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rl78.html" target="_blank">https://www.renesas.com/eu/en/products/microcontrollers-microprocessors/rl78.html</a><br>
The software manual which contains all there is to know about RL78 is available here:<br>
<a href="https://www.renesas.com/us/en/doc/products/mpumcu/doc/rl78/r01us0015ej0220_rl78.pdf" target="_blank">https://www.renesas.com/us/en/doc/products/mpumcu/doc/rl78/r01us0015ej0220_rl78.pdf</a><br>
<br>
The motivation behind this is the following:<br>
For the past 7 years I've been working on the Renesas RL78 and RX MCU ports in GCC (originally developed and maintained by Red Hat).<br>
In case of RX I have no real issues with GCC as performance is similar to the RX commercial/proprietary compilers,<br>
however in case of RL78 the performance(both code size and speed) of GCC is very poor it ranges from 20% to 300% worse compared to the RL78 commercial compilers (from Renesas and IAR Systems).<br>
<br>
I'm still a few months away from upstreaming the port but the port is currently quite stable and performance is very similar to the commercial/proprietary compilers (the machine outliner is very effective as RL78 has a very limited instruction set), and there's
still a lot of room for improvement.<br>
Also I'm able to keep ABI compatibility with the commercial compilers and implement features (available in the commercial compilers) which I wasn't able to do in GCC although I tried really hard for years.<br>
So I would like take this opportunity to say thank you to you all for making LLVM so great and ease to use and extend.<br>
<br>
Although I'm looking at other targets and follow the guidelines if there are pointers/suggestions which people would like to share I'm happy to listen.<br>
<br>
I would like to show just one short example which was my starting point and motivation to switch to LLVM:<br>
char foo(char a, char b, char c, char d, char e, char f) {<br>
return a + b + c + d + e + f;<br>
}<br>
<br>
This is what GCC produces (30 bytes and 18 clock cycles excluding the ret instruction)<br>
_foo:<br>
mova, [sp+14]<br>
movc, a<br>
mova, [sp+12]<br>
adda, c<br>
movc, a<br>
mova, [sp+10]<br>
adda, c<br>
movc, a<br>
mova, [sp+8]<br>
adda, c<br>
movc, a<br>
mova, [sp+6]<br>
adda, c<br>
movc, a<br>
mova, [sp+4]<br>
adda, c<br>
movr8, a<br>
ret<br>
While with I can produce the following output code (11 bytes and 5 clock cycles excluding the ret)<br>
Notice also the ABI difference (with LLVM I was able to use the same ABI as the commercial compilers)<br>
_foo:<br>
add a, x<br>
add a, c<br>
add a, b<br>
add a, e<br>
add a, d<br>
ret<br>
<br>
Please note the following comments are more directed at clang and I apologize if I shouldn't post here at all, I will repost the second part on cfe-dev list as well, but the first part of the email is about the announcement of the port and I think it belongs
here.<br>
<br>
Because I aim to replace GCC with LLVM, I already implemented the GCC RL78 attributes (__attribute__) and builtin functions (__builtin_rl78_*) however I recently received a request which brings me to the reason why I'm writing today:<br>
I was asked if I can implement the C Language extension from the Renesas CCRL (Renesas RL78 commercial compiler) in clang in order to close the gap between the two compilers.<br>
<br>
In GCC I implemented one of them (#pragma address) but when I pushed it upstream it wasn't met with too much enthusiasm and it didn't get accepted. I ended up maintaining it locally among many other things which I didn't upstream which made updating to new
versions of GCC difficult.<br>
This is one very important thing which I would like to avoid in LLVM, I don't want to do something that would not be accepted upstream and end up in the same situation as I was with GCC.<br>
<br>
My question here will be: are the following CCRL extensions acceptable to be implemented in clang? or will I find myself in the same situation as I am with GCC as they won't be accepted upstream? Especially since for most of them we already/can have alternative
implementations using __attribute__ and other approaches more in line with clang extensions.<br>
<br>
<br>
First things I would like to explain are the pragmas.<br>
Most CCRL pragmas have a trait which is quite unusual: the first parameter is function or a variable name, for example in order to declare a interrupt functions while in GCC I do:<br>
void inter ( void ) __attribute__((interrupt));<br>
In CCRL this is declared the following way:<br>
#pragma interrupt inter<br>
void inter ( void ) {<br>
}<br>
<br>
I haven't checked the clang source code but I imagine it is not straight forward to tie a pragma to a particular function declaration as there are no other such pragmas as far as I'm aware.<br>
<br>
The complete list of pragmas in question is:<br>
#pragma interrupt [(]interrupt-handler-name[(interrupt-specification [,...])][)]<br>
The equivalent of __attribute__((interrupt)) as discussed above.<br>
#pragma interrupt_brk [(]interrupt-handler-name[(interrupt-specification[,...])][)]<br>
The equvivalent of __attribute__((brk_interrupt)).<br>
#pragma section [ section-type][ new-section-name] section-type:{text|const|data|bss}<br>
#pragma inline [(]function-name [,...][)]<br>
#pragma noinline [(]function-name [,...][)]<br>
As the name says inline, noinline. We have inline, __inline and __inline__ keywords and __attribute__ ((always_inline)).<br>
#pragma inline_asm [(]function-name [,...][)]<br>
This pragma specifies the body of the function is assembly code.<br>
I image substantial changes will be required in clang for this.<br>
#pragma address [(]variable-name=absolute-address[,...][)]<br>
This can be implemented with __attribute((section("section-name")) and then handling that section in the linker script accordingly.<br>
And a few more pragmas for we could have equivalent __attribute__.<br>
#pragma saddr [(]variable-name[,...][)]<br>
#pragma near [(] function-name [,...][)]<br>
#pragma far [(] function-name [,...][)]<br>
#pragma callt [(]function-name[,...][)]<br>
#pragma stack_protector [(]function-name[(num=number)][,function-name[(num=number)]][,...][)]<br>
#pragma no_stack_protector [(]function-name[,...][)]<br>
<br>
Finally there are 2 operators:<br>
__sectop("section-name")<br>
__secend("section-name")<br>
This can be easily done by adding symbols at start and end of output sections in the linker script and referencing them from C as global pointers.<br>
<br>
<br>
The CCRL manual explaining those extension in detail is available here:<br>
<a href="https://www.renesas.com/us/en/doc/products/tool/doc/015/r20ut3123ej0109-ccrl.pdf" target="_blank">https://www.renesas.com/us/en/doc/products/tool/doc/015/r20ut3123ej0109-ccrl.pdf</a><br>
<br>
Best Regards,<br>
Sebastian<br>
<br>
<br>
<br>
<br>
Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB 3708 USt-IDNr./Tax identification
no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><u></u><u></u></span></font></p>
</blockquote>
</div>
</div>
</div>
<br>
<br>
<div></div>
<p style="font-size:8pt">Renesas Electronics Europe GmbH, Geschaeftsfuehrer/President: Carsten Jauch, Sitz der Gesellschaft/Registered office: Duesseldorf, Arcadiastrasse 10, 40472 Duesseldorf, Germany, Handelsregister/Commercial Register: Duesseldorf, HRB
3708 USt-IDNr./Tax identification no.: DE 119353406 WEEE-Reg.-Nr./WEEE reg. no.: DE 14978647
</p>
</div>
</blockquote></div></div>