Re: JIT Proof of Concept

[Max Brister]

On Mon, May 7, 2012 at 5:14 PM, John W. Eaton <address@hidden> wrote:
> On  7-May-2012, Max Brister wrote:
>
> | 4) It might be nice to separate type inference and code generation.
> | This would allow us to have variables with multiple possible types. I
> | think this would make supporting the possibility of undefined values
> | cleaner.
>
> I don't think we need to do type inferencing, do we?  I thought we
> were just planning to compile bits of code for a given set of types.
>
> jwe

Well, we still have to do type inference as a sanity check. For
example, take the loop
for i = 1:1000
  a = a + a;
  a = a + b;
endfor

If our initial type set is {a: scalar, b: matrix} we will compile the expression
a = a + a; to a = fpadd a, a
which is only correct for the first iteration. When we attempt to
compile the expression
a = a + b
we infer a + b is a matrix, and fail as we had assumed a was a scalar.

If we did type inference as a separate step, then we could infer that
a is a matrix and code compilation would work. (so long as we remember
to check for broadcasting in the case of a 1x1 matrix) I don't think
it should difficult to separate type inference from code generation.
We just need to add another pass over the AST. It should be faster in
the case that type inference fails, as we have not created the LLVM
function yet. Additionally, we can guarantee that if type inference
passes, code generation will pass. This means we don't need to worry
about cleaning up the LLVM function if code generation failure.

Max Brsiter