<div dir="ltr"><div>Hi Sebastian,</div><div dir="ltr"><br></div><div dir="ltr">On Wed, Apr 1, 2020 at 8:45 PM Sebastian Perta via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<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></blockquote><div><br></div><div>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.</div><div><br></div><div> *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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Dmitri</div></div><div><br></div>-- <br><div dir="ltr">main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if<br>(j){printf("%d\n",i);}}} /*Dmitri Gribenko <<a href="mailto:gribozavr@gmail.com" target="_blank">gribozavr@gmail.com</a>>*/</div></div>