Re: octave and LLVM google summer of code project

[Duncan Sands]

Hi John, I've added Max (the potential GSoC student) and some LLVM guys
to the CC list.

> I also think a JIT compiler for Octave would be useful, but I have some
> doubts about whether someone new to Octave could deliver something
> working in just 10 weeks.  But maybe it would be worth it just to have
> a starting point.

This is also our major concern: since Max has no previous experience with
either LLVM or octave internals, how much time will be lost getting up to
speed?  I think he would do well to start on the project now, playing with
the toy language in the LLVM tutorial, plugging debugging code into the
octave parser to see how it works etc.  That way he can get a better
appreciation of the project and show us that he is serious about it.

> As has also been discussed on the lists, you won't get much speed up
> if you simply transform the code into something that is compiled but
> still relies on dispatching in the octave_value class (the object that
> serves as a container for Octave matrix, scalar, cell array, struct,
> etc. data types).  You will only get a significant speedup if you can
> effectively infer data types from the Octave code itself (which has no
> type declarations).  So the hard part is type inferencing, not
> compiling to machine code that uses a library to implement the type
> dispatching.

I asked Chris about doing type inference, and he seemed to think
(based on past experience with similar sounding languages) that it
would be quite straightforward to do something that handles easy
cases, which tend to be the common cases.  Straightforward for
someone with experience of type inference of course...

> Octave already has a parser that constructs a tree structured
> representation of the code and also provides methods for walking the
> tree that I expect could be used to transform it to something suitable
> for LLVM.

Yes, that sounds like the right way to go.

Best wishes,

Duncan.