This is the mail archive of the
mailing list for the GCC project.
Re: GCC-Bridge: A Gimple Compiler targeting the JVM
- From: "Bertram, Alexander" <alex at bedatadriven dot com>
- To: Manuel LÃpez-IbÃÃez <lopezibanez at gmail dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 1 Feb 2016 23:21:23 +0100
- Subject: Re: GCC-Bridge: A Gimple Compiler targeting the JVM
- Authentication-results: sourceware.org; auth=none
- References: <CAOdV3zBHNvWMBPwkybvPzc9_yMndeP2bnxsXNGCbocwTHbPSWQ at mail dot gmail dot com> <56AFCD34 dot 5040204 at gmail dot com>
Thanks Mikhail and Manuel for the reactions!
Mikhail, thanks for the tip on xmalloc, will take a look if that can
help clean up the plugin code.
0) Yes, we hope to make it faster!
1) Initially coding within GCC would have been too intimidating, but I
think i've started to get a feel for the system and porting the
compiler to some sort of C++ module might be a good long term to
strategy to avoid drift as GCC internal evolve.
I'm not sure exactly where it would fit in however- I don't think it
could be described with the machine description language. There is
alot of complexity involved in handling things like addressable local
variables, which have to be allocated as unit length arrays so that we
can pass around a reference to them. Would it be possible to write a
backend that generates code from Gimple and not RTL?
2) I'm hoping we can get within 10-20% slowdown. However, the ultimate
goal is to be include "native" code in Renjin's auto parallelization
feature, which operates more on the level of aSQL query planner than
at the instruction level, which would lead to a net speedup.
That's the working hypothesis at least. I'm planning on doing a round
of benchmarking in the next 1-2 months along with a comparison of the
assembly generated by GCC on one hand for a given source, and the
assembly ultimately generated by the JVM's JIT compiler.
3) Good to know! Is this right the mailing list to ask questions about
some of the internal structure? The GCC Internals manual is very
useful, and the source provides a lot of answers, but sometimes I run
into questions, for example, on how exactly UNORDERED_EXPR is defined,
or how to access the byte offset for COMPONENT_REF expression when
field names vary.
On Mon, Feb 1, 2016 at 10:25 PM, Manuel LÃpez-IbÃÃez
> On 01/02/16 12:34, Bertram, Alexander wrote:
>> I wanted to share a project we've been working on for sometime within
>> the context of Renjin,
>> a new interpreter for the R language running on the JVM.
>> We basically needed a way to compile C and Fortran code to JVM
>> classes, and for the last year or two we've been working on tool chain
>> that's composed of a GCC plugin which dumps Gimple trees out to a JSON
>> file, and a Java program which reads the JSON and compiles it to Java
> This sounds interesting! (R is so slow)
> 1) Wouldn't it be better to directly compile to Java bytecode? I think GJC
> was able to do that in the past, but I'm not sure how bit-rotted that code
> is by now. https://gcc.gnu.org/ml/gcc/2000-02/msg00161.html It may be a more
> robust solution in the long run.
> 2) The reason that R uses so much C and Fortran code is because when
> compiled, that code is much faster than R. How much is lost by compiling and
> running in JVM?
> 3) Gimple is not completely target independent, but I think we would like to
> move towards that direction, so reporting bugs about that with specific
> testcases may be helpful. Of course, a JVM target would make this concern
>> Anyway, using the GCC plugin interface has been terrific, and the
>> gimple trees have been great to work with!
> Please, note that the plugin API is mainly driven by its users. If you want
> to see improvements, don't hesitate to propose patches.
Tel. Nederlands: +31(0)647205388