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

[Dmitri Gribenko via cfe-dev]

Hi Sebastian,

On Wed, Apr 1, 2020 at 8:45 PM Sebastian Perta via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

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

It would require a little infrastructure work, but I think it would be
quite doable. Generally, for your pragmas it seems like you might need to
extend support for attaching pragmas as attributes to functions. Please
take a look at how '#pragma omp declare' (for example, '#pragma omp declare
simd', '#pragma omp declare variant') are implemented.

*Assuming* that LLVM would be accepting the backend, and as long as you
scope the processing of these proprietary pragmas to your target and your
target only, I think there should be no issue.

However, given the advantages of standard attributes and general practice
in writing modern C and C++, it would be a lot better if we could avoid
proprietary pragmas, or at least have a plan towards removing them in
future.

Upgrading the compiler would not be completely transparent for your
customers anyway, some manual adjustments to the source code would be
necessary (for example, to get rid of other proprietary extensions and
reliance on implementation-defined behaviors, recover performance, fix bugs
uncovered by the new compiler etc.) I recommend that you provide a
source-to-source translation tool that translates the pragmas to
attributes, as well as translating the unusual assembly syntax into the
more widely accepted GCC asm extension. If the your current toolchain
supports that spelling, the customers could even run the tool, translate
the code to use a more widely accepted syntax, validate the changes using
the old toolchain (should be a no-op), and then migrate to Clang.

Implementing the inline assembler extension would be more difficult than
pragmas. Clang already supports MSVC's inline assembler
(see clang/test/CodeGen/ms-inline-asm-64.c, for example), but implementing
it was a major endeavor. It created non-trivial maintenance burden, because
the MSVC inline assembler allowed to incorporate some C and C++ expressions
and declaration references directly into the assembly commands. If your
dialect does not have such power, it might be easier to support, but again,
my best suggestion is to consider asking users to run a source-to-source
translation to the GCC inline asm extension, or the MSVC inline asm since
it is already supported in Clang and not going away.

Developing a source-to-source translation tool would be beneficial not just
for eliminating these pragmas and unusual inline asm, but also for
eliminating many other small incompatibilities between your proprietary
toolchain and Clang that you will undoubtedly find. While implementing
pragmas in Clang is realistic and practical, implementing bug-for-bug
compatibility for other issues is not, and customers would have to change
the code in order to upgrade the toolchain. While they do that, they could
as well run a source-to-source translation tool to eliminate pragmas and
unusual inline asm -- if the translation tool is reliable, those additional
edits would be trivial to review, compared to the effort needed to find and
eliminate other incompatibilities and newly found bugs.

Dmitri

-- 
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr at gmail.com>*/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200408/e36b0bba/attachment.html>