Philipp Schwaha
2013-Mar-01 14:23 UTC
[LLVMdev] 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
Duncan Sands
2013-Mar-01 15:58 UTC
[LLVMdev] dragon egg + llvm for fortran to c translation
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.
Óscar Fuentes
2013-Mar-01 15:58 UTC
[LLVMdev] dragon egg + llvm for fortran to c translation
Philipp Schwaha <philipp at 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.
Dmitry Mikushin
2013-Mar-01 16:02 UTC
[LLVMdev] dragon egg + llvm for fortran to c translation
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 at schwaha.net>> 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 > ______________________________**_________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/**mailman/listinfo/llvmdev<http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130301/f915decf/attachment.html>
Philipp Schwaha
2013-Mar-02 14:51 UTC
[LLVMdev] dragon egg + llvm for fortran to c translation
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 :) 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 On 03/01/2013 05:02 PM, Dmitry Mikushin wrote:> 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 at schwaha.net <mailto:philipp at schwaha.net>> > > 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 > _________________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu <mailto:LLVMdev at cs.uiuc.edu> > http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/__mailman/listinfo/llvmdev > <http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev> > >
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 at cs.uiuc.edu would have been the better list. Choosen llvmdev as I included questions ... /Andreas -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-CodeGen-support-for-llvm.umul_with_overflow-intrinsi.patch Type: text/x-patch Size: 3026 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130302/c6e73288/attachment.bin> -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-beautified-Interpreters-debug-output.patch Type: text/x-patch Size: 983 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130302/c6e73288/attachment-0001.bin> -------------- next part -------------- 0001-CodeGen-support-for-llvm.umul_with_overflow-intrinsi.patch 0002-beautified-Interpreters-debug-output.patch