7 ms·

This is precisely what we do in Renjin in order to translate C/Fortran to Java: https://github.com/bedatadriven/renjin/blob/master/tools/gcc-bridge-plugin/src/

This is precisely what we do in Renjin in order to translate C/Fortran to Java: https://github.com/bedatadriven/renjin/blob/master/tools/gcc-bridge-plugin/src/main/c/plugin.c https://github.com/bedatadriven/renjin/blob/master/tools/gcc... This little plugin simply dumps GCC's gimple to JSON, yielding for example: https://github.com/bedatadriven/renjin/blob/master/tools/gcc-bridge/src/test/resources/org/renjin/gcc/dqrdc2.f.json https://github.com/bedatadriven/renjin/blob/master/tools/gcc... LLVM's design looks very attractive, but for scientific computing Fortran is really important, and AFAICT, LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple, but perhaps I just haven't looked deep enough.

bedatadriven 12y ago
I should mention that the only problem we have this approach is that neither the AST structure nor the plugin API is guaranteed to be stable between releases, so if you want to use Renjin's full tool chain, you have to be able to install a copy of GCC 4.6.x locally, which only gets more difficult over time. This is the actual point of debate: RMS wants to keep these APIs moving targets in order to discourage Intel or whoever from writing a compiler that just shells out to gcc to handle all of the parsing. Unfortunately, fully GPL'd, open-sourced projects like our own (and who knows how many others that were never even started because of these artificial hurdles) are the ones most affected.
buttproblem 12y ago
> LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple LLVM variables are sometimes called registers but they are machine independent. The bit width is arbitrary (e.g., you can create a 129-bit integer). The use of the term register is a misleading analogy; often LLVM-IR is compared to assembly language so the use of the term register was also used. I do not know GIMPLE and couldn't find a good description of the IR instructions. But, it seems that LLVM IR is somewhat similar to low GIMPLE.
- bedatadriven 12y ago
  Will have to take another look, but it still sounds to me like LLVM IR is more comparable to RTL (https://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL https://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL). Gimple variables have types comparable with C types - you get pointers, arrays. For example: int sum10(int values[10]) { int i; int sum = 0; for(i=0;i<10;++i) { sum += values[i]; } values[0] = 342; return sum; } is compiled down to: sum10 (int * values) { long unsigned int D.1598; long unsigned int D.1599; int * D.1600; int D.1601; int D.1602; int i; int sum; sum = 0; i = 0; goto <D.1595>; <D.1594>: D.1598 = (long unsigned int) i; D.1599 = D.1598 * 4; D.1600 = values + D.1599; D.1601 = *D.1600; sum = D.1601 + sum; i = i + 1; <D.1595>: if (i <= 9) goto <D.1594>; else goto <D.1596>; <D.1596>: *values = 342; D.1602 = sum; return D.1602; }
  - rwallace 12y ago
    As far as I know, LLVM does exactly the same thing; the LLVM representation of that code would have a different syntax of course, but semantically would be exactly equivalent to the Gimple version you've presented.

bedatadriven 12y ago

I should mention that the only problem we have this approach is that neither the AST structure nor the plugin API is guaranteed to be stable between releases, so if you want to use Renjin's full tool chain, you have to be able to install a copy of GCC 4.6.x locally, which only gets more difficult over time. This is the actual point of debate: RMS wants to keep these APIs moving targets in order to discourage Intel or whoever from writing a compiler that just shells out to gcc to handle all of the parsing. Unfortunately, fully GPL'd, open-sourced projects like our own (and who knows how many others that were never even started because of these artificial hurdles) are the ones most affected.

buttproblem 12y ago

> LLVM doesn't have an intermediate representation comparable to Gimple: LLIR seems to be at the level of the registers rather than the nice abstract Gimple LLVM variables are sometimes called registers but they are machine independent. The bit width is arbitrary (e.g., you can create a 129-bit integer). The use of the term register is a misleading analogy; often LLVM-IR is compared to assembly language so the use of the term register was also used. I do not know GIMPLE and couldn't find a good description of the IR instructions. But, it seems that LLVM IR is somewhat similar to low GIMPLE.

bedatadriven 12y ago
Will have to take another look, but it still sounds to me like LLVM IR is more comparable to RTL (https://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL https://gcc.gnu.org/onlinedocs/gccint/RTL.html#RTL). Gimple variables have types comparable with C types - you get pointers, arrays. For example: int sum10(int values[10]) { int i; int sum = 0; for(i=0;i<10;++i) { sum += values[i]; } values[0] = 342; return sum; } is compiled down to: sum10 (int * values) { long unsigned int D.1598; long unsigned int D.1599; int * D.1600; int D.1601; int D.1602; int i; int sum; sum = 0; i = 0; goto <D.1595>; <D.1594>: D.1598 = (long unsigned int) i; D.1599 = D.1598 * 4; D.1600 = values + D.1599; D.1601 = *D.1600; sum = D.1601 + sum; i = i + 1; <D.1595>: if (i <= 9) goto <D.1594>; else goto <D.1596>; <D.1596>: *values = 342; D.1602 = sum; return D.1602; }
- rwallace 12y ago
  As far as I know, LLVM does exactly the same thing; the LLVM representation of that code would have a different syntax of course, but semantically would be exactly equivalent to the Gimple version you've presented.