[cfe-dev] question about possible new extensions (mainly pragmas) in clang for new LLVM backend for Renesas RL78 MCU

[Sebastian Perta via cfe-dev]

Hello all,

I just made an announcement on the llvm-dev list about a new LLVM backend for the Renesas RL78 MCU which I'm writing:
http://lists.llvm.org/pipermail/llvm-dev/2020-April/140546.html

Because I aim to replace GCC with LLVM, I already implemented the GCC RL78 attributes (__attribute__) and builtin functions (__builtin_rl78_*) and I don't have any real concern about getting those attributes and builtins accepted upstream however I recently received a new request:
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.
However I am little bit concerned with those extension as they are a little bit unusual compared to what I see in clang.

A few years ago I implemented one of them in GCC (#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 which I something that I want to avoid with clang/llvm I don't want to do something that would not be accepted upstream.

My question here will be: are the following CCRL extensions acceptable to be implemented in clang? especially since for most of them we already/can have alternative implementations using __attribute__ and other approaches more in line with clang extensions.


First things I would like to explain are the pragmas.
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:
void inter ( void ) __attribute__((interrupt));
In CCRL this is declared the following way:
#pragma interrupt inter
void inter ( void ) {
}

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.

The complete list of pragmas in question is:
#pragma interrupt [(]interrupt-handler-name[(interrupt-specification [,...])][)]
The equivalent of __attribute__((interrupt)) as discussed above.
#pragma interrupt_brk [(]interrupt-handler-name[(interrupt-specification[,...])][)]
The equvivalent of __attribute__((brk_interrupt)).
#pragma section [ section-type][ new-section-name] section-type:{text|const|data|bss}
#pragma inline [(]function-name [,...][)]
#pragma noinline [(]function-name [,...][)]
As the name says inline, noinline. We have inline, __inline and __inline__ keywords and __attribute__ ((always_inline)).
#pragma inline_asm [(]function-name [,...][)]
This pragma specifies the body of the function is assembly code.
I image substantial changes will be required in clang for this.
#pragma address [(]variable-name=absolute-address[,...][)]
This can be implemented with __attribute((section("section-name")) and then handling that section in the linker script accordingly.
And a few more pragmas for we could have equivalent __attribute__.
#pragma saddr [(]variable-name[,...][)]
#pragma near [(] function-name [,...][)]
#pragma far [(] function-name [,...][)]
#pragma callt [(]function-name[,...][)]
#pragma stack_protector [(]function-name[(num=number)][,function-name[(num=number)]][,...][)]
#pragma no_stack_protector [(]function-name[,...][)]

Finally there are 2 operators:
__sectop("section-name")
__secend("section-name")
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.


The CCRL manual explaining those extension in detail is available here:
https://www.renesas.com/us/en/doc/products/tool/doc/015/r20ut3123ej0109-ccrl.pdf

Best Regards,
Sebastian



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