dragon egg + llvm for fortran to c translation

hi!

I would like to know if it is feasible to use the dragon egg gcc plugin to automatically convert fortran code to c. Having found that it is possible to output llvm byte code back to c (at least something like this gave me this impression/hope: llc -march=c -o test.c) I am hoping to use dragon egg to generate the byte code from fortran 90 which than output to c.
Does this seem feasible at all? How much in terms of variable names etc. could be retained in this manner?

thanks for any suggestions or comments
    Philipp

Hi Philipp,

I would like to know if it is feasible to use the dragon egg gcc plugin to
automatically convert fortran code to c. Having found that it is possible to
output llvm byte code back to c (at least something like this gave me this
impression/hope: llc -march=c -o test.c) I am hoping to use dragon egg to
generate the byte code from fortran 90 which than output to c.
Does this seem feasible at all? How much in terms of variable names etc. could
be retained in this manner?

some people have already been doing this. There were some minor issues but on
the whole it seems it worked OK. The big problem is that LLVM's C backend has
been removed, so you would have to use an old version of LLVM (or help out with
bringing the C backend back to life).

Ciao, Duncan.

Philipp Schwaha <philipp@schwaha.net> writes:

I would like to know if it is feasible to use the dragon egg gcc
plugin to automatically convert fortran code to c. Having found that
it is possible to output llvm byte code back to c (at least something
like this gave me this impression/hope: llc -march=c -o test.c) I am
hoping to use dragon egg to generate the byte code from fortran 90
which than output to c.

The C backend was removed from LLVM some time ago, so your llc recipe
won't work with a recent or development version. Some people showed
interest on resurrecting the C backend but so far it didn't materialize.

Does this seem feasible at all?

Feasible? yes. Practical? I don't think so. But that depends on your
specific goals, of course.

How much in terms of variable names
etc. could be retained in this manner?

I don't think that the resulting C code would be pleasant to read, and
most of the original Fortran names (except perhaps for function names)
would be lost.

DragonEgg only converts GCC’s IR to LLVM IR. And -march=c is C backend. We used it for a while last year, but its support has been dropped several months ago. There are people, who are still using it privately, as far as I know.

  • D.

2013/3/1 Philipp Schwaha <philipp@schwaha.net>

Thank you for your reply Dmitry!

It would not be too great a deal, if I need to use previous versions as
long as it would get the desired results :slight_smile:
Would the code from the IR be portable to different C compilers? I
guess the resulting C code will not have too much resemblance to the input?

cheers
  Philipp

Hi Philipp,

Let me provide you with an example back from September 2011. Attached is original Fortran source, optimized LLVM IR and what we regenerated back into C from LLVM IR by means of C backend. As you can see, the C code closely resembles LLVM IR.

I don’t know what you intend to use it for (maybe some source-to-source compiler or DSL?), but to our experience, we had a system using C backend, but dropped it in favor of native LLVM backend for the target architecture (NVPTX in our case). Source-to-sourcing is generally very painful, there is a great chance to spend 90% of resources on stupid technical problems and only 10% - for ideas/innovation.

Note we were only users of C backend, and only had to make minor fixes to a working system. Developers are Chris, Duncan (replied on this thread too) and others. They may have more insight, if you would need implementation details.

Best,

  • D.

2013/3/2 Philipp Schwaha <philipp@schwaha.net>

sincos.sincos_loop_1_kernelgen.c.device.F90 (425 Bytes)

sincos.sincos_loop_1_kernelgen.c.device.F90.ir.c (12 KB)

sincos.sincos_loop_1_kernelgen.c.device.F90.opt.ir (3.28 KB)

Hello all,

I have played a little bit with the lli interpreter - realising that not all of the intrinsic functions have been implemented.
Digging a bit deeper I have prepared a small patch to extend the intrinsinc lowering capability.
As of now only llvm.umul.with.overflow is added - in order to verify if I have got the point ... comments welcome.

The second change is more a question ...
Is there a reason for the interpreter to omit the new line after its "About to interpret: " debug message ?
In my opinion the output arrangement is better with adding line breaks after every instruction - rather than printing them endlessly.

Finally since I'm not sure the modification as such is fine - I was also not sure wheter llvm-commits@cs.uiuc.edu would have been the better list.
Choosen llvmdev as I included questions ...

/Andreas

0001-CodeGen-support-for-llvm.umul_with_overflow-intrinsi.patch (2.96 KB)

0002-beautified-Interpreters-debug-output.patch (983 Bytes)

PatchSet (112 Bytes)

Hi Dmitry,

thank you very much for the very illuminating example!

Hi Philipp,

Let me provide you with an example back from September 2011. Attached
is original Fortran source, optimized LLVM IR and what we regenerated
back into C from LLVM IR by means of C backend. As you can see, the C
code closely resembles LLVM IR.

yes, the resemblance is quite remarkable.

I don't know what you intend to use it for (maybe some
source-to-source compiler or DSL?), but to our experience, we had a
system using C backend, but dropped it in favor of native LLVM backend
for the target architecture (NVPTX in our case). Source-to-sourcing is
generally very painful, there is a great chance to spend 90% of
resources on stupid technical problems and only 10% - for
ideas/innovation.

source to source is exactly what would be the goal. I realize it is a quite painful process and thus would like to use as much existing infrastructure as possible before reinventing already excellent solutions.

Note we were only users of C backend, and only had to make minor
fixes to a working system. Developers are Chris, Duncan (replied on
this thread too) and others. They may have more insight, if you would
need implementation details.

thank you very much for all your help, it is very much appreciated!

best regards
    Philipp