[bitc-dev] Bringup decisions

[Sandro Magi]

I don't mean to take up your valuable time, so feel free to ignore these
questions. I'm just curious about the conclusions on LLVM. Shap already
posted his analysis of C-- so I'm not so curious on that front. ;-)


Swaroop Sridhar wrote:
> I don't think going to LLVM would have reduced a lot of effort in the 
> current compiler.
> 
> i) As far as I know -- and I might be wrong -- LLVM only has a c or c++ 
> like frontend that is full supported.

And a few toy implementations that serve as tutorials, like Stacker.

> In that case, much of what we are 
> doing is necessary anyway. Of course, producing LLVM code would have the 
> advantage that we could then use the LLVM interpreter for debugging, etc.

And the LLVM community. Long-term support is often underestimated, as is
distributed development.

> ii) The other option was to use the LLVM interfaces to emit LLVM 
> bytecode directly.

Why wouldn't you use LLVM's in-memory representation?

> Even in this case, all phases including SSA transform 
> phase are necessary.

I don't understand what you mean by this. Unless this is implied by
emitting LLVM bytecode directly rather than using the in-memory IR.

> We would have a LLVM emission phase instead of the 
> final C emission phase. This would also require some sort of register 
> allocation.

If I understand correctly, register allocation happens in an LLVM pass
on the SSA form. What sort of manual register allocation you would need
to do?

> iii) The other advantage in going to LLVM would be that we can use 
> LLVM's accurate GC, but we would have to emit GC-roots and type 
> information. (We are now relying on the Boehm collector for the 
> bootstrap compiler).

You could just as easily rely on Boehm within LLVM and avoid using the
GC intrinsics.

Sandro